Documentation: define a policy for requirements to plugins beyond kubernetes standard (e.g. cvmfs) #229
Description
Having multiple sidecars for multiple backend is fantastic, and kubernetes provides a detailed standard to which they will all do their best to adhere.
Unfortunately, some "special usecase" for our workflows escapes the standard and we need to define a common "language" to enable and/or configure each specific feature.
A few examples:
- in the slurm plugin, we define the queue of the target batch system using annotations
- in the docker plugin, we embed the ssh-forwarding for interactive jupyter sessions in the docker image
- in the kubernetes plugin, we mount cvmfs based on the name of the volume
It would be nice to converge towards a common mechanism and a well defined space of configurations we tend to move towards while developing plugins.