Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Gliffy Diagram
nameOpenWhisk-activation-flow-warmed-action
pagePin23

  1. The request arrives from a client
  2. Authentication and Authorization
    1. The Action Container Router validates the Authorization header with OpenWhisk Auth Service
    2. The response of the Auth Service is cached 
  3. Routing
    1. Check namespace limits
    2. Forward the request to a container selected from a list of warmed actions that the Action Router keeps. 
      1. 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
      2. Websockets could also be supported, another missing feature in OpenWhisk.
  4. Action Container Proxy sidecar
    1. Check action concurrency limit
    2. 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
  5. Invoke the action and return the response
    1. Caching the action response could be another nice to have feature, which is not implemented in OpenWhisk. Caching would should be configured from controller by the action response.
  6. Collect activation info.
  7. Sequence support. If the action is part of a sequence, then the Router should have logic to invoke the next action in the sequence.

...

When the Action Proxy is at capacity, it should return a 429 message back to the Action RouterContainer Router. A Retry-After  header could specify <delay-seconds>  or <http-date>  for a CircuitBreaker in the ContainerRouter so the router doesn't retry again. The time window for retry should ideally be computed from the response times observed by the Container Proxy. 

TBD

Control Plane

Candidates:

...