incubator-openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Crossley <>
Subject Re: SPI PRs: LoadBalancer, ActivationExecutor, ContainerFactory
Date Tue, 22 Aug 2017 22:44:07 GMT
Hi Tyson,

Thanks for spearheading this SPI effort. Much appreciated!

As a "Kube folk" who has taken a stab at a ContainerFactory SPI [1], I
think we also need to encapsulate the cleanup() function defined in
InvokerReactive within the ContainerFactory interface [2]. The factory
impls are going to know best how to delete all the containers they create,
and those docker calls currently used in IR.cleanup() won't work on all
kube-like platforms, e.g. OpenShift.



On Tue, Aug 22, 2017 at 1:40 PM, Tyson Norris <>

> Hi -
> I wanted to give a nudge for comments on these PRs, as well as provide
> some context:
> #2584 - LoadBalancer - to allow alternative load balancers (e.g.
> not-kafka, concurrent, multiple executors, etc)
> #2656 - ActivationExecutor - (builds on 2584) adds an abstraction *below*
> load balancer for enabling multiple execution workflows; an example
> provided is “kind based”, such that different action kinds can be executed
> by particular ActivationExecutor (with a fallback to the default
> Kafka/invoker based executor which still can handle everything). Existing
> LoadBalancerService implements both LoadBalancer and ActivationExecutor
> #2659 - ContainerFactory - this one is simply providing an approach for
> defining how containers are managed, which can be used to enable
> mesos/kube/etc container launching/killing/etc. (Kube folks, I’m looking at
> you for feedback on this)
> Let me know if you have comments either via GitHub for individual PR
> questions, or let’s discuss on list if there is some general overall
> feedback to these (design, etc), since they are somewhat all related to the
> flow of activation execution.
> Upcoming additional related items:
> - concurrent ActivationExecutor (does container pool, but with concurrent
> requests and without message queues)
> - logging (to allow alternate log collection, storage, and retrieval -
> e.g. we want to decouple log collection from OW processing jvms and
> delegate to an separate API for retrieving logs on demand)
> - authentication (not related to execution paths directly, but this is
> floating on our radar)
> Thanks for any feedback
> Tyson

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message