openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Glikson" <>
Subject Re: Improving support for UI driven use cases
Date Sat, 01 Jul 2017 16:36:29 GMT
Having different policies for different container pools certainly makes 
sense. Moreover, enhancing the design/implementation so that there is more 
concurrency and less bottlenecks also sounds like an excellent idea. 
However, I am unsure specifically regarding the idea of handling multiple 
requests concurrently by the same container. For example, I wonder how one 
would determine the desired resource allocation for such container? 
Wouldn't this re-introduce issues related to sizing, scaling and 
fragmentation of resources - nicely avoided with single-tasked containers? 
Also, I wonder what would be the main motivation to implement such a 
policy compared to just having a number of hot containers, ready to 
process incoming requests?


From:   Rodric Rabbah <>
Cc:     Dragos Dascalita Haut <>
Date:   01/07/2017 06:56 PM
Subject:        Re: Improving support for UI driven use cases

Summarizing the wiki notes:

1. separate control and data plane so that data plane is routed directly 
the container
2. desire multiple concurrent function activations in the same container

On 1, I think this is inline with an outstanding desire and corresponding
issues to take the data flow out of the system and off the control message
critical path. As you pointed out, this has a lot of benefits - including
one you didn't mention: streaming (web socket style) in/out of the
container. Related issues although not complete in [1][2].

On 2, I think you are starting to see some of the issues as you think
through the limits on the action and its container and what that means for
the user flow and experience. Both in terms of "time limit" and "memory
limit". I think the logging issue can be solved to disentangle 
But I also wonder if these are going to be longer running "actions" and
hence, the model is different: short running vs long running container for
which there are different life cycles and hence different scheduling
decisions from different container pools.


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