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? Cheers Markus Am 13. September 2017 um 07:44 schrieb Tyson Norris <[email protected]>: Hi - Following SPI PRs need feedback (in order) , as interested people have time: - LoadBalancer SPI - https://github.com/apache/incubator-openwhisk/pull/2584 - delegates loadbalancer creation to the SPI - Multiple LoadBalancers SPI - https://github.com/apache/incubator-openwhisk/pull/2668 - 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 - https://github.com/apache/incubator-openwhisk/pull/2659 - 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 managers) - LogStore SPI - https://github.com/apache/incubator-openwhisk/pull/2695 - 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! Best Tyson
