Bug 2278642 - [4.14.z clone] ocs-operator should not be annotating all openshift-* namespaces
Summary: [4.14.z clone] ocs-operator should not be annotating all openshift-* namespaces
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenShift Data Foundation
Classification: Red Hat Storage
Component: ocs-operator
Version: 4.14
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: ODF 4.14.8
Assignee: Nikhil Ladha
QA Contact: Elad
URL:
Whiteboard:
: 2267606 2278578 (view as bug list)
Depends On: 2276135
Blocks: 2278568
TreeView+ depends on / blocked
 
Reported: 2024-05-02 14:16 UTC by Mudit Agarwal
Modified: 2024-06-12 07:38 UTC (History)
10 users (show)

Fixed In Version: 4.14.8-3
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 2276135
Environment:
Last Closed: 2024-06-12 07:38:51 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github red-hat-storage ocs-operator pull 2577 0 None Merged remove namespace controller 2024-05-27 06:49:34 UTC
Github red-hat-storage ocs-operator pull 2594 0 None open Bug 2278642: [release-4.14] remove namespace controller 2024-05-27 06:48:59 UTC
Red Hat Product Errata RHBA-2024:3861 0 None None None 2024-06-12 07:38:59 UTC

Description Mudit Agarwal 2024-05-02 14:16:09 UTC
+++ This bug was initially created as a clone of Bug #2276135 +++

Description of problem
======================

The ocs-operator should not add `reclaimspace.csiaddons.openshift.io/schedule`
annotation to all openshift-* namespaces, because it could get into conflict
with another operator which doesn't expect this annotation to be there.

One such conflict arises when ODF is installed on ARO cluster: ARO operator is
trying to get rid of this annotation on ARO namespaces (openshift-azure-loggin
or openshift-azure), so that it effectively prevents ODF to be installed on ARO.

The change was introduced via
https://github.com/red-hat-storage/ocs-operator/pull/2074

The annotation itself seems to control ODF "reclaim space operation"[1], so
there is no reason to label all openshift namespaces in the first place.

[1] https://access.redhat.com/documentation/en-us/red_hat_openshift_data_foundation/4.10/html/managing_and_allocating_storage_resources/reclaiming-space-on-target-volumes_rhodf

Version-Release number of selected component
============================================

ODF 4.14

How reproducible
================

100%

Steps to Reproduce
==================

1. Install ODF on ARO 4.14 cluster

Actual results
==============

ARO Operator is removing `reclaimspace.csiaddons.openshift.io/schedule`
annotation from ARO namespaces.

Example from aro-operator-master log:

```
time=2024-04-19 16:43:10.000000 level=info msg=""
Update Namespace/openshift-azure-logging: u00a0u00a0&v1.Namespace{
    u00a0u00a0 TypeMeta: {},
    u00a0u00a0 ObjectMeta: v1.ObjectMeta{
        u00a0u00a0             ... // 9 identical fields
        u00a0u00a0             DeletionGracePeriodSeconds: nil,
        u00a0u00a0             Labels:                     {
            "kubernetes.io/metadata.name": "openshift-azure-logging",
            "pod-security.kubernetes.io/audit": "privileged",
            "pod-security.kubernetes.io/enforce": "privileged",
            "pod-security.kubernetes.io/warn": "privileged"
        },
        u00a0u00a0             Annotations: map[string]string{
            u00a0u00a0                 ... // 2 identical entries
            u00a0u00a0                 "openshift.io/sa.scc.supplemental-groups":	"1000680000/10000",
            u00a0u00a0                 "openshift.io/sa.scc.uid-range":                "1000680000/10000",
            -u00a0                     "reclaimspace.csiaddons.openshift.io/schedule": "@weekly",
            u00a0u00a0
        },
        u00a0u00a0             OwnerReferences: {
                {
          	 APIVersion: "aro.openshift.io/v1alpha1",
                Kind: "Cluster",
                Name: "cluster",	
                UID: "1b821b4f-2dcc-4ae7-ab57-452df1ad678b",                     	
                ...
            }
        },
        u00a0u00a0             Finalizers:	 nil,
        u00a0u00a0             ManagedFields:   {
                {
                Manager: "Go-http-client",
                Operation: "Update",
                APIVersion: "v1",
                Time: s"2024-04-19 08:41:38 +0000 UTC",
                ...
            },
          	 {
                Manager: "cluster-policy-controller",
                Operation: "Update",
                APIVersion: "v1",
                Time: s"2024-04-19 08:41:38 +0000 UTC",
                ...
            },
                {
                Manager: "ocs-operator",
                Operation: "Update",
                APIVersion: "v1",
                Time: s"2024-04-19 16:43:10 +0000 UTC",
                ...
            }
        },	
        u00a0u00a0
    },
    u00a0u00a0 Spec:   {
        Finalizers: {"kubernetes"}},
    u00a0u00a0 Status: {Phase: "Active"},
    u00a0u00a0
}       
```

Expected results
================

ODF doesn't annotate all openshift namespaces, but only those which needs that annotation only.

--- Additional comment from Martin Bukatovic on 2024-04-19 19:17:17 UTC ---

See also:

- https://redhat-internal.slack.com/archives/CCV9YF9PD/p1713546395182889

--- Additional comment from RHEL Program Management on 2024-04-19 19:17:31 UTC ---

This bug having no release flag set previously, is now set with release flag 'odf‑4.16.0' to '?', and so is being proposed to be fixed at the ODF 4.16.0 release. Note that the 3 Acks (pm_ack, devel_ack, qa_ack), if any previously set while release flag was missing, have now been reset since the Acks are to be set against a release flag.

--- Additional comment from RHEL Program Management on 2024-04-19 19:17:31 UTC ---

The 'Target Release' is not to be set manually at the Red Hat OpenShift Data Foundation product.

The 'Target Release' will be auto set appropriately, after the 3 Acks (pm,devel,qa) are set to "+" for a specific release flag and that release flag gets auto set to "+".

--- Additional comment from Eran Tamir on 2024-04-21 04:26:57 UTC ---

@muagarwa this is a blocker for ARO 4.14. Can you please prioritize it or provide a workaround we can include in ARO instructions?

--- Additional comment from Madhu Rajanna on 2024-04-22 05:38:47 UTC ---

The requirement was to support reclaimspace for all the namespaces starting with openshift-* https://issues.redhat.com/browse/RHSTOR-4468, @Eran i think we cannot workaround because if we add any annotation on this namespace its getting removed by the operator, if we know the exact name need to be discarded we can blocklist that in ocs-operator code. let me know if that works and what is the exact name we need to consider here.

--- Additional comment from Nikhil Ladha on 2024-04-22 05:57:48 UTC ---

From the slack thread it looks like "openshift-managed-upgrade-operator" and "openshift-azure-logging" are the 2 namespaces that is managed by that operator.
Though, please let me know if we should be just blocklisting these 2 namespaces or how it should be?

--- Additional comment from Martin Bukatovic on 2024-04-22 07:39:11 UTC ---

ARO namespaces are:

- openshift-azure-logging
- openshift-azure-operator

That said I need to point out that the design choice selected in RHSTOR-4468 is the root cause here.

The proper solution is to add the annotation *only* to namespaces which are using ODF backed rbd storage.

--- Additional comment from Madhu Rajanna on 2024-04-22 07:55:05 UTC ---

>The proper solution is to add the annotation *only* to namespaces which are using ODF backed rbd storage.

This will be a heavy thing to do for this simple use case, Fow not we are not going to hardcode anything

Suggested changes in ocs-operator as below

* DO restart only once when ocs-operator is starting only if the annotation is added
* Skip Reconcile update operation on the namespace as it's not required.

--- Additional comment from Eran Tamir on 2024-05-01 09:15:51 UTC ---

Discussed offline and got to agreement on the required change.

--- Additional comment from RHEL Program Management on 2024-05-02 07:45:23 UTC ---

This BZ is being approved for ODF 4.16.0 release, upon receipt of the 3 ACKs (PM,Devel,QA) for the release flag 'odf‑4.16.0

--- Additional comment from RHEL Program Management on 2024-05-02 07:45:23 UTC ---

Since this bug has been approved for ODF 4.16.0 release, through release flag 'odf-4.16.0+', the Target Release is being set to 'ODF 4.16.0

Comment 2 Nikhil Ladha 2024-05-02 15:03:10 UTC
*** Bug 2278578 has been marked as a duplicate of this bug. ***

Comment 5 Nikhil Ladha 2024-05-28 09:34:06 UTC
*** Bug 2267606 has been marked as a duplicate of this bug. ***

Comment 7 Yuli Persky 2024-05-30 21:54:00 UTC
A clarification - This BZ is Azure specific bug. It was not seen on any of the other platform. 

For verification : the following command should be run on some ( no need to test all) of the openshift-* namespaces: 

oc get ns openshift-storage -o yaml | grep "reclaimspace"

Comment 8 Yuli Persky 2024-05-30 22:09:13 UTC
I've checked in ARO cluster (https://ocs4-jenkins-csb-odf-qe.apps.ocp-c1.prod.psi.redhat.com/job/qe-trigger-azure-managed-aro-3az-rhcos-3m-3w-tier1/15/)  installed with 4.14.8-4 the annotations of openshift-* namespaces. 
No annotation that looks like "reclaimspace.csiaddons.openshift.io/schedule" was on any of the openshift-* namespaces. 
Explicetely checked openshift-azure-logging , openshift-cloud-credential-operator, 
openshift-monitoring, openshift storage namespaces, also other. 

Therefore this BZ is verified , changing the status.

Comment 13 errata-xmlrpc 2024-06-12 07:38:51 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 (Red Hat OpenShift Data Foundation 4.14.8 Bug Fix Update), 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-2024:3861


Note You need to log in before you can comment on or make changes to this bug.