SPI for ContainerProxy and ContainerPool

[style95]

As of now, SPI concept is applied in many parts of OpenWhisk.
If same concept is applied to ContainerProxy and ContainerPool, it would give users more options and make OW more flexible.

[style95]

closing as #4453 is merged.

Now we have SPI for InvokerReactive.
It would include corresponding ContainerProxy and ContainerPool.

[koraa]

Hiho!

Can we reopen this?

I am currently looking for a way to run some custom code whenever a container is provisioned with an actual action (both for stem cells and completely new containers). We are providing some extra services as part of our platform that need to be configured with some action-specific data which are however not part of the action itself.

In order to achieve this I would like to SPI ContainerProxy; we could simply subclass it, intercepting the state transitions…
I'd be happy to implement the SPI, but I would like to get some feedback from the openwhisk community as this would be the first openwhisk feature I am working on…

Thanks for your great work on openwhisk!

[koraa]

Oh and I realize this could be implemented using the InvokerReactive; however we would have to basically copy and paste it just changing the childFactory field to create our custom proxy instead, which does not seem like the most maintainable way to go ahead with this…

[style95]

@koraa Hi.
Thank you for bringing this up.
The reason why I made SPI for InvokerReactive is, it is highly likely ContainerPool and ContainerProxy are dependent on InvokerReactive.

I am not quite sure which logic do you need to execute, but if you just want to add some custom logic in ContainerProxy only, I feel it would be better to add functionality to inject some logic dynamically or make it executed dynamically via feature flag.

[koraa]

We just need to intercept the state transitions; not change the actual behavior.
I don't think adding a feature flag to openwhisk for very specific behavior we need would be accepted by the openwhisk maintainers…and maintaining a fork is not really an option…

add functionality to inject some logic dynamically

You mean an event listener?