Supported path for CSI drivers that need a node DaemonSet
維護者通常 1 天內回覆
還沒有人認領這個 Issue。
評估
研究方向
Read the registry+v1 validator at internal/operator-controller/rukpak/render/registryv1/validators/validator.go#L355-L364 and the supported resource list in operator-registry/pkg/lib/bundle/supported_resources.go#L33-L56, then review draft PR #3057 and discussion #2992. The issue asks maintainers to choose a supported direction for CSI DaemonSets, so clarify the v1 bundle and compatibility design before implementation.
由索引模型根據 Issue 內容生成。
描述
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?
- 主要語言
- Go
- 星號
- 215
- 分支
- 86
- 平均合併
- 1 天 6 小時
- 30 天內合併 PR
- 124
環境準備
- 沒有 Dockerfile 或 Docker Compose 檔案
- 有 Pull Request 範本
- 閱讀貢獻指南
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
operator-framework/operator-controller 的其他 Issue
-
難度 4/5 3-5 天 新手友好度 46/100
operator-framework/operator-controller#3042 ·
維護者通常 1 天內回覆
-
lifecycle/stale
難度 4/5 3-5 天 新手友好度 52/100
operator-framework/operator-controller#2861 · 1 則留言 ·
維護者通常 1 天內回覆
-
Add OCIImage SourceType to ClusterExtension API可能重新可做 @grokspawn 於 58 天前認領，目前沒有進行中的 PR。 未關閉
operator-framework/operator-controller#2686 · 2 則留言 · 已指派 1 人 ·
維護者通常 1 天內回覆
-
難度 4/5 3-5 天 新手友好度 48/100
operator-framework/operator-controller#2680 · 2 則留言 · 1 個 reaction ·
維護者通常 1 天內回覆
-
[epic] OLMv1: Support feature-gated APIs可能重新可做 @tmshort 於 541 天前認領，目前沒有進行中的 PR。 未關閉epic v1.x
operator-framework/operator-controller#1975 · 3 則留言 · 已指派 1 人 ·
維護者通常 1 天內回覆
查看 operator-framework/operator-controller 的全部 Issue
相似的 Issue
-
meta
難度 2/5 1-3 小時 新手友好度 62/100
last9/last9-mcp-server#554 ·
維護者通常 1 天內回覆
-
難度 1/5 1 小時以內 新手友好度 85/100
-
NodeOpUpgrade copies Pod resolv.conf into host OS, causing CoreDNS loops and image-pull failures未關閉area/operator bug chore
難度 2/5 1-3 小時 新手友好度 76/100
維護者通常 1 天內回覆
-
難度 1/5 1 小時以內 新手友好度 86/100
DNSCrypt/dnscrypt-resolvers#1107 ·
-
backend in-progress task
難度 1/5 1 小時以內 新手友好度 90/100
jphacks/kz_2601#2101 · 1 則留言 ·
維護者通常 1 天內回覆