NETOBSERV-2225 - Deploy static plugin at operator startup - fix

[jpinsonneau]

Description

Fix namespace reconciliation when create by the user.
Since #1345 openshift.io/cluster-monitoring: "true" is missing when the user created the namespace by himself.

Dependencies

n/a

Checklist

If you are not familiar with our processes or don't know what to answer in the list below, let us know in a comment: the maintainers will take care of that.

• Is this PR backed with a JIRA ticket? If so, make sure it is written as a title prefix (in general, PRs affecting the NetObserv/Network Observability product should be backed with a JIRA ticket - especially if they bring user facing changes).
• Does this PR require product documentation?
  • If so, make sure the JIRA epic is labeled with "documentation" and provides a description relevant for doc writers, such as use cases or scenarios. Any required step to activate or configure the feature should be documented there, such as new CRD knobs.
• Does this PR require a product release notes entry?
  • If so, fill in "Release Note Text" in the JIRA.
• Is there anything else the QE team should know before testing? E.g: configuration changes, environment setup, etc.
  • If so, make sure it is described in the JIRA ticket.
• QE requirements (check 1 from the list):
  • Standard QE validation, with pre-merge tests unless stated otherwise.
  • Regression tests only (e.g. refactoring with no user-facing change).
  • No QE (e.g. trivial change with high reviewer's confidence, or per agreement with the QE team).

[jotak]

thanks!
/lgtm

[memodi]

/ok-to-test

[github-actions]

New images:

• quay.io/netobserv/network-observability-operator:11b17e4
• quay.io/netobserv/network-observability-operator-bundle:v0.0.0-sha-11b17e4
• quay.io/netobserv/network-observability-operator-catalog:v0.0.0-sha-11b17e4

They will expire after two weeks.

To deploy this build:

# Direct deployment, from operator repo
IMAGE=quay.io/netobserv/network-observability-operator:11b17e4 make deploy

# Or using operator-sdk
operator-sdk run bundle quay.io/netobserv/network-observability-operator-bundle:v0.0.0-sha-11b17e4

Or as a Catalog Source:

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: netobserv-dev
  namespace: openshift-marketplace
spec:
  sourceType: grpc
  image: quay.io/netobserv/network-observability-operator-catalog:v0.0.0-sha-11b17e4
  displayName: NetObserv development catalog
  publisher: Me
  updateStrategy:
    registryPoll:
      interval: 1m

[memodi]

this does not work, when I created namespace with label openshift.io/cluster-monitoring: "true"

cat <<EOF | oc apply -f -

apiVersion: v1
kind: Namespace
metadata:
labels:
openshift.io/cluster-monitoring: "true"
name: openshift-netobserv-operator
EOF

after installing flowcollector openshift.io/cluster-monitoring: "true" is removed:

$ oc get ns/netobserv -o yaml
apiVersion: v1
kind: Namespace
metadata:
  annotations:
    openshift.io/sa.scc.mcs: s0:c25,c20
    openshift.io/sa.scc.supplemental-groups: 1000640000/10000
    openshift.io/sa.scc.uid-range: 1000640000/10000
    security.openshift.io/MinimallySufficientPodSecurityStandard: privileged
  creationTimestamp: "2025-07-25T19:47:53Z"
  labels:
    kubernetes.io/metadata.name: netobserv
    netobserv-managed: "true"
    pod-security.kubernetes.io/audit: privileged
    pod-security.kubernetes.io/audit-version: latest
    pod-security.kubernetes.io/warn: privileged
    pod-security.kubernetes.io/warn-version: latest
  name: netobserv
  resourceVersion: "34102"
  uid: f6987279-9a04-40a4-afff-55e05f04a27b
spec:
  finalizers:
  - kubernetes
status:
  phase: Active

/needs-changes

[jotak]

@memodi I guess you didn't set the downstream deployment env set to true, did you?
I can reproduce what you say if I don't set it, but not if I set it. This works as expected when I try.

[openshift-ci]

New changes are detected. LGTM label has been removed.

[jpinsonneau]

@memodi @jotak what about merging previous labels and annotations in any case ?

a6d2a24

That's a new behavior but I feel it better match the needs here

[github-actions]

New images:

• quay.io/netobserv/network-observability-operator:7d34a6a
• quay.io/netobserv/network-observability-operator-bundle:v0.0.0-sha-7d34a6a
• quay.io/netobserv/network-observability-operator-catalog:v0.0.0-sha-7d34a6a

They will expire after two weeks.

To deploy this build:

# Direct deployment, from operator repo
IMAGE=quay.io/netobserv/network-observability-operator:7d34a6a make deploy

# Or using operator-sdk
operator-sdk run bundle quay.io/netobserv/network-observability-operator-bundle:v0.0.0-sha-7d34a6a

Or as a Catalog Source:

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: netobserv-dev
  namespace: openshift-marketplace
spec:
  sourceType: grpc
  image: quay.io/netobserv/network-observability-operator-catalog:v0.0.0-sha-7d34a6a
  displayName: NetObserv development catalog
  publisher: Me
  updateStrategy:
    registryPoll:
      interval: 1m

[openshift-ci]

@jpinsonneau: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/e2e-operator	a6d2a24	link	false	/test e2e-operator

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

[memodi]

@memodi I guess you didn't set the downstream deployment env set to true, did you?

@jotak you're right, my script needed to be updated for DOWNSTREAM_VAR index change.

[memodi]

@jpinsonneau - sorry, I missed with previous image due to this reason, I am able to see correct behavior even with previous image .

Sorry for the false alarm, I guess we could revert a6d2a24 ?

[jpinsonneau]

@jpinsonneau - sorry, I missed with previous image due to this reason, I am able to see correct behavior even with previous image .

Sorry for the false alarm, I guess we could revert a6d2a24 ?

I'll let @jotak decide on that once since it's a new behavior which make sense to me.

[jotak]

This behaviour (keeping labels) makes sense to me, just trying to catch any potential side-effect...
For instance if there is an old label/annotation that we want to remove, it's not going to be removed. But, does that happen? I just see the corner case of having the openshift-monitoring annotation already set up, and we switch the downstream-deployment flag to false, which should make the annotation disappear, but it won't work here I guess. I say it's a corner case because normally we don't play with the downstream-deployment flag after the fact, it's either set or unset from the start, especially we hardly never want to unset it... wdyt?

[jotak]

but honestly I though we were already keeping previous labels/annotations ...

[jotak]

or we should perhaps keep a hard-coded list of labels/annotations explicitly managed by us that we don't want to preserve from old revisions?

[jpinsonneau]

but honestly I though we were already keeping previous labels/annotations ...

We kind of do it as we don't update when not necessary but currently we override everything if it needs changes.

or we should perhaps keep a hard-coded list of labels/annotations explicitly managed by us that we don't want to preserve from old revisions?

I don't want overengineering here. I'd prefer to keep the previous approach if you feel this is incomplete as is

[jotak]

ok then I'd say let's revert to keep previous behaviour, and we can think about a more complete fix if someone complains at some point

[jpinsonneau]

Removed a6d2a24 commit

[memodi]

/label qe-approved

thanks, let's merge this asap so perf runs can get back on track.

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

Approval requirements bypassed by manually added approval.

This pull-request has been approved by:

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment