Skip to content

Should not install Subscriptions in openshift-operators with manual approval #1365

Description

@faust64

As of experimenting with RHOAI3, we noticed some new subscription installed in openshift-operators namespace

Which I guess comes from here:
https://github.com/openshift/cluster-ingress-operator/blob/master/pkg/operator/controller/gatewayclass/subscription.go

OpenshiftOperatorNamespace = "openshift-operators"

Would it please be possible to install that subcription somewhere else?
Over time, we can't install new operators, nor upgrade existing ones, as any approval will include that ServiceMesh operator upgrade:

spec:
  approval: Manual
  approved: false
  clusterServiceVersionNames:
  - opentelemetry-operator.v0.140.0-2
  - devworkspace-operator.v0.38.0
  - servicemeshoperator3.v3.2.1
  - kiali-operator.v2.17.3
  - devspacesoperator.v3.24.1
  - servicemeshoperator.v2.6.13
  - openshift-gitops-operator.v1.16.5
  generation: 2279

Or would it be OK to upgrade that operator? Why manual approvals?

Why should the ingress controller operator be responsible of installing additional operators?

Side question: I do already have servicemesh 3 installed on some cluster. We're currently running from latest in stable-3.2 channel.
How would ingress operator cope with mismatching SM3 versions? For a single OCP version, there may be lots of new channels and versions coming over time.

Metadata

Metadata

Assignees

No one assigned

    Labels

    lifecycle/rottenDenotes an issue or PR that has aged beyond stale and will be auto-closed.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions