SPI for ContainerProxy

[koraa]

Hi!

I am currently looking for a way to run some custom code whenever a container is provisioned with an actual action in Adobe I/O Runtime (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…

Alternatively it would be possible to implement some sort of Event listening scheme, although I do not think that would fit very well into the existing Openwhisk code base?

Thanks for your great work on openwhisk!

[koraa]

This topic has been discussed before in here: https://github.com/apache/openwhisk/issues/3662; in that particular issue InvokerReactive has been SPIed instead, since coupling between InvokerReactive and ContainerPool/ContainerProxy is pretty tight…

However I think this issue represents a good use case for SPIing ContainerProxy since using the InvokerReactive SPI would mean a lot of code duplication for us…

[style95]

@koraa Sorry for the late response. I missed your comment in the previous thread.

As I shared in the previous thread, my first impression on this is, one option can be adding a pre-processing hook and/or post-processing hook. For example, we are creating a container with ContainerFactory.createContainer. If we add an optional processing hook in this method, we can easily add some custom logic.

Since it might not work in your case, it would be great if you share more details about what you need to achieve and where your changes are supposed to be placed.

And I am also curious how other folks think about this.

[koraa]

Hiho!

A hook in createContainer wouldn't work AFAICS as a container may be created without loading an action (creating a stem cell). A hook/event based approach would of course work (we just need to place the hook at the right state transition in ContainerProxy), I am just not sure it would be the most flexible/integrate well with the existing code. Of course if you all decided a hook would be a better I would be happy to implement a hook based solution. Is there any example of a hook based api in openwhisk that I could use as guidance when creating a hook for action provisioning?

Regarding our use case: What kind of information would you like to have? We want to provide platform/runtime level facilities for our actions that need to be provisioned for the specific action; we would not like to change the docker runtime or the action itself to provide these services (for security reasons/running in a separate security enclave & because it is more convenient for the user).

In the specific case we would like to be able to customize how logging is handled on a per client basis (send log messages in real time to user configured logging sinks).

[tysonnorris]

Hi - Can you elaborate why this should not be an aspect of the runtime image? ContainerProxy manages the state only from perspective of the ContainerPool, and the runtime image manages the state from the perspective of container state - so I think what you describe probably belongs in the runtime image.

Within the image, you have a few options for affecting the state of the container:

• build it into the image
• do something during /init
• do something during /run

Can you give a concrete example of We want to provide platform/runtime level facilities for our actions that need to be provisioned for the specific action?

Also, have you considered doing these things in a separate action as part of a sequence or composition?