You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've always found it strange how bulky defining any given CSI deployment can be. Having to specify 7 separate container images is just... ugh. I'd like to have a conversation to at least understand why things are this way and if there's a better way to specify the image versions of the various CSI containers.
To start, I would think it'd be appropriate for the upstream Ceph-CSI drivers to specify their own set of container images for a given version/release of the drivers. Would it be possible to do something as simple as publishing a YAML manifest, either on GitHub or in a container image or something, with these values where anyone could just look them up as needed?
Alternatively, as we're seeing with this repo, we could take the part of the ClusterVersion controller in #7 that does the image specification and spin it off into its own container image to run in a Job. For the most part, unless actively developing the driver, anyone using it would just install it once and never touch it again until upgrade time, right? This also ties in to the idea of gutting the ClusterVersion controller almost entirely, except for maybe the SCC (i.e. OpenShift-specific) stuff. Broadly speaking, as long as the core driver doesn't have any k8s dependencies, a small, k8s-specific deployer image doesn't sound unreasonable. And there's no reason to keep it tied specifically to this operator, Rook, or anything else.
I've always found it strange how bulky defining any given CSI deployment can be. Having to specify 7 separate container images is just... ugh. I'd like to have a conversation to at least understand why things are this way and if there's a better way to specify the image versions of the various CSI containers.
To start, I would think it'd be appropriate for the upstream Ceph-CSI drivers to specify their own set of container images for a given version/release of the drivers. Would it be possible to do something as simple as publishing a YAML manifest, either on GitHub or in a container image or something, with these values where anyone could just look them up as needed?
Alternatively, as we're seeing with this repo, we could take the part of the ClusterVersion controller in #7 that does the image specification and spin it off into its own container image to run in a Job. For the most part, unless actively developing the driver, anyone using it would just install it once and never touch it again until upgrade time, right? This also ties in to the idea of gutting the ClusterVersion controller almost entirely, except for maybe the SCC (i.e. OpenShift-specific) stuff. Broadly speaking, as long as the core driver doesn't have any k8s dependencies, a small, k8s-specific deployer image doesn't sound unreasonable. And there's no reason to keep it tied specifically to this operator, Rook, or anything else.
Taken from: #7 (comment)
Referencing: #7 (comment)
The text was updated successfully, but these errors were encountered: