openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Thömmes <>
Subject Re: PR feedback for SPIs
Date Wed, 13 Sep 2017 15:08:30 GMT
Hi Tyson,

first of all: Thanks for the great effort put into all of these SPI implementations. Here
are some general comments from myself on SPIs

The ContainerFactory SPI feels natural and makes a lot of sense to support different deployment
models. There is no doubt about that one from my side.

For the LoadBalancer SPIs though, I am quite worried that we're silently rebuilding all of
OpenWhisk's underlying architecture without anybody really noticing it. It feels to me that
OpenWhisk is then becoming a set of plugins and you cannot compare any performance data anymore,
neither do different implementors look at the very same bottlenecks. We talked about the direct
Loadbalancer for instance and I still feel like it is not to be conflated with the use-case
of having concurrent requests to containers and thus higher density on invokers. In fact,
if you feel you need a direct Loadbalancer, would it maybe even make sense to have that one
globally instead of just for that specific type of actions? I'd like to keep synergy effects
high in the projects and I strongly feel that we're missing out on those if we start to break
the system apart and stop being opinionated about the implementations we've chosen.

As for the logstore I kinda feel the same for now, although I haven't looked thoroughly.
It does feel like it should at least partly be unified with the ContainerFactory SPI since
getting to logs always is a concern of the underlying container implementation (i.e.: Which
log drivers are supported etc.).

What do you think?


Am 13. September 2017 um 07:44 schrieb Tyson Norris <>:

Hi -
Following SPI PRs need feedback (in order) , as interested people have time:

- LoadBalancer SPI - - delegates loadbalancer
creation to the SPI

- Multiple LoadBalancers SPI - - allows
multiple load balancers, loaded via the previous SPI, resolved per action via LoadBalancerResolver;
allows either single loadbalancer (current behavior) or kind based loadbalancer (config maps
action kinds to a specific loadbalancer); this will allow things like latency sensitive actions
routing to containers directly while latency insensitive actions route via Kafka, etc. Relies
on previous

- ContainerFactory SPI - - delegates
container instantiation to an SPI; Affected areas are InvokerReactive; also moved the dependent
classes (Container et al) to common/scala, to allow for other cases (e.g. controller causes
container launch, etc); TBD: checking maxActiveContainers and maxPoolSize should be part of
this SPI too, but currently are not. (e.g. maxActiveContainers may be dynamic with some cluster

- LogStore SPI - - enables log collection
to be delegated to an decoupled system (instead of consuming cycles within the invoker JVM);
Affected areas are ContainerProxy (log collection delegates to the SPI), RestAPIs (delegate
log retrieval to the SPI), and ContainerFactory impls (delegate docker run --log-opt parameters
to the SPI); still needs some cleanup (WIP). Relies on ContainerFactory, mostly since it organizes
Container classes around the ones moved to common/scala

Building on these some upcoming additions include:
- direct LoadBalancer - allow controller to route actions directly to shared containers (i.e.
to support better throughput with fewer containers, if the action supports it, via multiple
loadbalancers - one for kafka+invoker routing, and one for direct container routing)
- mesos ContainerFactory - to support launching containers in a mesos cluster (run more containers
with fewer, or just 1, invokers per cluster, since the invoker has access to the entire mesos
cluster for container launching)

Let me know via comments in PR (or on dev list) if you have questions on these.

Thanks in advance for feedback!

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