Documentation: define a policy for requirements to plugins beyond kubernetes standard (e.g. cvmfs)

[landerlini]

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.

[dciangot]

@Bianco95 @Surax98 can you summarize the status on this? What's the plan for the first implementation?

[dciangot]

I think this is more appropriate as a github discussion, I don't think we ever reached a definiteve answer here.