openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Crossley <jcros...@redhat.com>
Subject Re: SPI PRs: LoadBalancer, ActivationExecutor, ContainerFactory
Date Wed, 23 Aug 2017 17:46:18 GMT
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 <jcrossle@redhat.com> 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 <tnorris@adobe.com.invalid>
> 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
>
>
>

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