In general we enforce a naming convention on namespaces created within the reserved openshift-* namespace - related components should either be in the same namespace (when there is no isolation boundary needed) or within a subset (like openshift-storage-operators-*). For operators required for the core platform to function, those operators should be part of openshift-storage-operators or a subset unless there is a security or resource usage boundary (additional namespaces creates cognitive load on admins and other parts of the system). So openshift-csi-snapshot-controller Active 38m openshift-csi-snapshot-controller-operator Active 38m should be in openshift-storage and openshift-storage-operator since CSI is a fundamental part of the platform. In general specific component names are for our team's benefit, but have a cost to customers, so sharing namespaces like the monitoring operator is appropriate (openshift-monitoring includes the monitoring stack, openshift-monitoring-operator is the thing that runs it).
Summary of discussion on Slack: 1. Namespace openshift-storage is taken by OCS and we don't want to use it for OCP operators. 2. We should put OCP storage stuff into: openshift-cluster-storage-operators with OCP operators: - openshift-cluster-storage-operator - openshift-csi-snapshot-controller-operator openshift-cluster-storage-controllers with the operands: - openshift-csi-snapshot-controller Moving openshift-cluster-storage-operator from openshift-cluster-storage-operator to openshift-cluster-storage-operators looks safe, the operator does not mind running twice in a cluster (too much). Moving openshift-csi-snapshot-controller into openshift-cluster-storage-operators during upgrade is hard, it *must* run only once in a cluster. To avoid elaborate go code to ensure the upgrade is smooth, we're going to change the namespace via updating CVO manifests in 4.4 before it's released. As consequence, in 4.4 we will have both openshift-cluster-storage-operators and openshift-cluster-storage-operator namespace. They will be merged in 4.5.
Per the comment: As consequence, in 4.4 we will have both openshift-cluster-storage-operators and openshift-cluster-storage-operator namespace. They will be merged in 4.5. $ oc get ns|grep storage openshift-cluster-storage-controllers Active 4h45m openshift-cluster-storage-operator Active 4h45m openshift-cluster-storage-operators Active 4h45m $ oc get pod -n openshift-cluster-storage-controllers NAME READY STATUS RESTARTS AGE csi-snapshot-controller-5b6455dfbb-9tgq9 1/1 Running 0 4h27m $ oc get pod -n openshift-cluster-storage-operator NAME READY STATUS RESTARTS AGE cluster-storage-operator-67745d8649-jfj67 1/1 Running 0 4h34m $ oc get pod -n openshift-cluster-storage-operators NAME READY STATUS RESTARTS AGE csi-snapshot-controller-operator-56f59b47b6-wv9mx 1/1 Running 0 4h45m Found there are both openshift-cluster-storage-operator and openshift-cluster-storage-operators namespace in 4.5, so marked this bug as ASSIGNED. But I think this is patch is good for 4.4.
I want to merge the namespaces in a separate BZ - I filed bug #1816941. In this bug I'd like to focus only on moving CSI snapshot parts to the new namespace, so I can backport the fix. Can you please mark it as VERIFIED, so github bots let me merge 4.4 cherry-pick?
Got it, then I'll mark this bug as verified.
Talked to Clayton again. We can put everything (all storage operators *and* their operands) into openshift-cluster-storage-operator namespace, so we don't need to rename existing namespace. Patch will follow shortly.
Verified with: 4.5.0-0.nightly-2020-03-25-223812 $ oc get ns|grep storage openshift-cluster-storage-operator Active 163m openshift-kube-storage-version-migrator Active 157m openshift-kube-storage-version-migrator-operator Active 163m $ oc get pod -n openshift-cluster-storage-operator NAME READY STATUS RESTARTS AGE cluster-storage-operator-749488c695-cmxhq 1/1 Running 0 153m csi-snapshot-controller-6b97cd747b-wqlsm 1/1 Running 0 146m csi-snapshot-controller-operator-6b5859fdb7-sv4jm 1/1 Running 0 163m
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:2409