Bug 1815552

Summary: Core storage operators should exist in the openshift-storage-operators namespace, and operands in openshift-storage or openshift-storage-*
Product: OpenShift Container Platform Reporter: Clayton Coleman <ccoleman>
Component: StorageAssignee: Jan Safranek <jsafrane>
Status: CLOSED ERRATA QA Contact: Qin Ping <piqin>
Severity: high Docs Contact:
Priority: unspecified    
Version: 4.5CC: aos-bugs, jsafrane, piqin
Target Milestone: ---   
Target Release: 4.5.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1816826 (view as bug list) Environment:
Last Closed: 2020-07-13 17:23:29 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1816826    

Description Clayton Coleman 2020-03-20 14:48:36 UTC
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).

Comment 1 Jan Safranek 2020-03-24 15:33:27 UTC
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.

Comment 4 Qin Ping 2020-03-25 07:10:05 UTC
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.

Comment 5 Jan Safranek 2020-03-25 08:23:51 UTC
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?

Comment 6 Qin Ping 2020-03-25 08:47:26 UTC
Got it, then I'll mark this bug as verified.

Comment 7 Jan Safranek 2020-03-25 14:52:09 UTC
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.

Comment 9 Qin Ping 2020-03-26 04:18:30 UTC
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

Comment 11 errata-xmlrpc 2020-07-13 17:23:29 UTC
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