Summarizing the wiki notes: 1. separate control and data plane so that data plane is routed directly to 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 activations. 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. [1] https://github.com/apache/incubator-openwhisk/issues/788 [2] https://github.com/apache/incubator-openwhisk/issues/254
