Enhancement request to support init containers for Pravega

[sarlaccpit]

Description

The Pravega controller supports a pluggable interface AuthHandler which allows implementers to provide their own authentication and authorization implementation.

To enable a Pravega controller process to load a custom implementation of the interface, one simply has to drop in the corresponding jar in /opt/..../plugins.

However that simple task tends to be somewhat unnecessarily complicated in the Kubernetes/docker world, since that means the implementer has to build a new docker image, based on the Pravega stock image, to include the new library.

Importance

The above complicates iterative development of the plugin implementation and forces non stock Pravega images to exist.

Location

N/A

Suggestions for an improvement

A more efficient way could be the following: provide a way to supply an init-container image to the PravegaCluster resource. The operator would pick up on that and inject the init container image into the pravega controller Deployment, for the purpose of transferring jars (a common pattern with init containers in K8).

The operator would then insure to copy the jar librarie(s) from the initcontainer to an emptyDir volume type, then from the emptyDir to the plugin directory, as part of the normal lifecycle of the Pravega controller pod.

Something very similar was done for the Schema Registry project chart, which also uses the AuthHandler interface.

For Pravega proper, it would have to be allowed in the PravegaCluster spec and handled by the Pravega operator.

To ease the injection of the plugin implementation even further, we could make the integration of the init container even more specific and guided than what the Schema registry did. In other words, The proposal would be for the PravegaCluster spec to have a new field along the lines of:

authImplementations:
-image1:1.0
-image2:5.3
...

The responsibility of the implementer of the supplied image(s) would be to provide a docker image which contains in a known location (say /plugins/implementation/) a valid jar with the implementation of the AuthHandler interface.

At deployment time, the Pravega operator would then:

1. cycle through the authImplementations list, and insert as many init containers as there are images, in the controller Deployment. For each initcontainer of the controller pod, it would provide the command to execute, which would be cp /plugins/implementation/*.jar /some-mapped-volume-based-on-emptydir-type).

2. Next, the operator would map that same emptyDir volume into the controller pod, under some location, say /some-well-known-source-dir-for-plugins.

3. Next, the Pravega image itself, would need, in its startup script, a pre command to copy the contents of /some-well-known-source-dir-for-plugins into /opt/.../plugins.

Alternatively (to 3 above), it could potentially also map the emptyDir volume, (now loaded with the jar files) directly under /opt/..../plugins if that is possible.

What this achieves:

As an implementer of the AuthHandler interface, I can simply keep patching the authImplementations field of the PravegaCluster resource and have the operator automatically restart my controller with the new libraries in place.

That would greatly decouple Pravega proper from its plugin implementations at runtime.