| ...
- 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.
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. ... |
