...
The Control Plane should provide an API used by the Data Plane to cold-start actions, and it should also emit events each time a change in the resource allocation happens; each time GC removes idle containers, or each time a new action is created, the Control Plane should notify all Data Plane instances of such changes.
Info |
---|
To be detailed: Unlike the current OW, the system is "async by default". The new design is "sync by default". The open question is how to handle async cases. |
Data Plane
The data plane layer invokes actions as fast as possible. When an action needs to be cold-started, the data plane delegates this to the Control Plane, awaiting for the action to become ready before invoking it. Once an action is warmed-up the data plane is notified, and if it was waiting for such event in order to invoke an activation, it should resume the execution.
...
- The request arrives from a client
- Authentication and Authorization
- The Container Router validates the Authorization header with OpenWhisk Auth Service
- The response of the Auth Service is cached
- Routing
- Check namespace limits
- Forward the request to a container selected from a list of warmed actions that the Action Router keeps.
- (new) Streaming the request to the action would be a nice; OpenWhisk doesn't have support for this, and such feature could remove the max payload limits
- (new) Websockets could also be supported, another missing feature in OpenWhisk.
- Container Proxy sidecar
- Check action concurrency limit
- Buffer a few more requests, queueing them into an overflow buffer; this may be something useful when cold-start could take longer than just queuing a few more requests. Blackbox actions that need to download the docker image may benefit from this more. This idea is inspired from KNative Serving.
- Invoke the action and return the response
- (new) Caching the action response could be another nice to have feature, which is not implemented in OpenWhisk. Caching should be controller by the action response.
- Collect activation info.
- Sequence support.
- If the action is part of a sequence, then the Router should have logic to invoke the next action in the sequence.
- Other ideas to explore to support sequences, should the support in the ContainerRouter is too difficult to implement
- ContainerProxy could "understand" sequences
- Or reuse Composer and implement sequence-as-an-action.
- Other ideas to explore to support sequences, should the support in the ContainerRouter is too difficult to implement
- If the action is part of a sequence, then the Router should have logic to invoke the next action in the sequence.
Flow for cold-start
When the Action Proxy is at capacity, it should return a 429 message back to the Container Router. A Retry-After
header could specify <delay-seconds>
or <http-date>
for a CircuitBreaker in the ContainerRouter to avoid routing to that action. The time window for retry should ideally be computed from the response times observed by the Container Proxy.
...