LGTM. One question is, is that intended to delegate action creation to the external system as well? For example, `createContainer` here means creating Lambda function and invoking it so that we need `ExecutableWhiskAction(codes)`?
Dominic 2019년 9월 6일 (금) 오후 3:11, Chetan Mehrotra <chetan.mehro...@gmail.com>님이 작성: > Gentle reminder bump for https://github.com/apache/openwhisk/pull/4595 > - Its changing the SPI semantics so please have a look and review! > Chetan Mehrotra > > On Wed, Aug 28, 2019 at 3:41 AM Chetan Mehrotra > <chetan.mehro...@gmail.com> wrote: > > > > For enabling some integration flows like delegating action execution > > to other systems like AWS Lambda or Azure Functions via > > ContainerFactory approach we need access to the action details. > > > > Currently there are 2 modes when a container is to be created > > > > 1. Prewarm case - Here `ContainerPool` would try to create containers > > for pre warm support. Here we do not the action for which container is > > being used > > > > 2. Cold Start - In case of Cold start when we do not have any existing > > container to use then a new container would be created. Here we know > > the action for which the container is being created > > > > If we want to implement a custom ContainerFactory which delegates the > > other system then it would be needing the Action details to route to > > matching Lambda/Azure Function. > > > > This PR [1] enables such integration by extending the ContainerFactory > > trait to support an option Action parameter. This would be set in cold > > start case. This change would be backward compatible and only those > > Factory implementation which need access to action would need to > > implement the new method > > > > Please review the PR and provide feedback on approach. Once we have an > > agreement I can add suitable tests > > > > Chetan Mehrotra > > [1] https://github.com/apache/openwhisk/pull/4595 >
