Repository navigation
Supported path for CSI drivers that need a node DaemonSet #3056
Description
CSI drivers usually ship a controller Deployment and a node plugin DaemonSet. In registry+v1 the Deployment fits the CSV, but the renderer rejects the DaemonSet through operator-registry's supported kinds. So CSI operators create it at runtime from their own controller; I could not find a certified or community bundle that ships one.
I asked about this in 2023 on the closed #1022 and in discussion #2992. Since then the experimental Helm chart gate was removed (#2798) and the next bundle format is still open, so I would like to know the supported path in OLM v1 for a CSI driver that needs a node DaemonSet.
One option I tried, in draft PR #3057: an Alpha gate, off by default, that lets the registry+v1 renderer accept a DaemonSet with the alpha BoxcutterRuntime, plus a DaemonSet progression probe. It is about 50 lines of production code and does not touch operator-registry. OLM v0 cannot use such a bundle: opm accepts it into a catalog, but on install v0 creates the CSV, skips the DaemonSet as unsupported and fails the InstallPlan, leaving the operator half installed. So a bundle that uses the gate is v1 only, and nodeSelector and tolerations through spec.config are not covered yet. Is a gate like this a direction you would consider for v1, or should CSI operators keep creating the DaemonSet from their controller until the next bundle format?
Activity
joelanford commentedon Oct 23, 2026
We don't intend to continue adding incremental support for new object types to registry+v1 bundles, especially in a way that makes OLMv0 and OLMv1 have different supported kinds. That entire approach has significant version skew issues that make it very easy to accidentally attempt installation of bundles with older versions of OLM that do not support the new bundle formats.
We do still intend on shipping support for helm charts. Our focus has been on bringing OLMv1 to the point that we can announce an OLMv0 deprecation. Once that hurdle is surpassed, helm support is the next priority.
We have been working a bit behind the scenes to line helm support up:
Once all three of those things land in operator-controller, DaemonSets (and any other API past, present, and future) will be supported.
cniackz commentedon Oct 23, 2026
Thank you @joelanford, this is very helpful. I had looked at the v0 install failure for this one bundle, but not at the broader version skew of growing registry+v1 with kinds that older OLM releases do not support, and I agree it is better not to go that way. Thank you also for laying out the path: #2907 for direct bundle references, the Helm OCI puller in library-olm, and the renderer prototype. I will follow the OLMv1 Helm support, and I am happy to help test it with a CSI driver once those pieces land. I am closing #3057 in favor of that path.
cniackz commentedon Oct 23, 2026
@joelanford a follow-up on the Helm path. We ship DirectPV, a CSI driver, as a Red Hat certified operator: today a Helm Operator renders its chart from a CR, mostly so the node DaemonSet is created at runtime. OLM v1 rendering the chart directly would remove that layer, and I would like to move DirectPV to it once it lands. Since certified content reaches clusters through catalogs, are charts planned to ship through catalogs after the direct OCI references? I am also asking Red Hat about certification, but if you know who decides whether Helm content installed by OLM v1 is eligible, a pointer would help.