One other thing, Tyson, related to that cleanup() function. You'll note that it refers to the invoker's InstanceId to find its containers. So I think we'll want to add InstanceId to getContainerFactory's parameter list. We use this in the kube impl to attach a label for each created container denoting its invoker. This makes it trivial to delete them all in one call.
Jim On Tue, Aug 22, 2017 at 6:44 PM, Jim Crossley <[email protected]> wrote: > 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. > > Thanks, > Jim > > [1] https://github.com/projectodd/incubator-openwhisk/blob/kube-container- > openshift/core/invoker/src/main/scala/whisk/core/containerpool/ > ContainerProvider.scala > [2] https://github.com/projectodd/incubator-openwhisk/blob/kube-container- > openshift/core/invoker/src/main/scala/whisk/core/invoker/ > InvokerReactive.scala#L69-L73 > > On Tue, Aug 22, 2017 at 1:40 PM, Tyson Norris <[email protected]> > wrote: > >> 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 > > >
