Hi Markus, 

Thanks for the prompt response and the pointer to your proposal.  Indeed, 
there is a synergy between this Lean OW proposal and the more far fetching 
changes that you suggest. The similarity is that Invoker's role is 
basically being done by controller with no Kafka in between to directly 
route to the warm containers (which are collocated with the controller in 
case of an IoT gateway where the lean OW will be deployed).

I believe that the main difference is that  in Lean OpenWhisk, we are not 
proposing any changes to the code of the core project. It's about simply 
using SPI to dynamically load the right load balancer and the queue object 
and having controller together with invoker as one executable without 
changing Invoker's code. 

So I believe the lean OW design will cause very little friction with the 
current base and will be easy to merge. Later on when the new design 
matures this same pattern of SPI can be used to extend controller's LB to 
talk HTTP with the action containers directly as you suggest. 

Hope this makes sense.

Cheers.

-- david & Pavel 

On 2018/07/16 11:24:47, "Markus Thoemmes" <[email protected]> 
wrote: 
> Hi David,
> 
> please send your PR for sure! IIRC we made the Loadbalancer pluggable 
specifically for this use-case. Sounds like a great addition to our 
possible deployment topologies.
> 
> Shameless plug: Would you review the architecture I proposed here: 
https://lists.apache.org/thread.html/29289006d190b2c68451f7625c13bb8020cc8e9928db66f1b0def18e@%3Cdev.openwhisk.apache.org%3E

> 
> In theory, this could make your proposal even leaner in the future. 
Don't hear me say though we should hold this back, we can absolutely go 
forward with your implementation first. Just wanted to quickly verify this 
use-case will also work with what we might plan for in the future.
> 
> Cheers,
> Markus
> 
> 

-- david 


Reply via email to