Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -7,6 +7,7 @@ metadata:
include.release.openshift.io/ibm-cloud-managed: "true"
include.release.openshift.io/self-managed-high-availability: "true"
include.release.openshift.io/single-node-developer: "true"
capability.openshift.io/name: Console
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can add this annotation to include.release.openshift.io/hypershift cluster-profile manifests, because openshift/hypershift#6183 is still in flight trying to make "HyperShift clusters with Console disabled" an option.

However, this particular manifest also belongs to other cluster profiles, like the default include.release.openshift.io/self-managed-high-availability. You cannot add the Console capability annotation to those, because there are already self-managed-high-availability clusters with the Console disabled and the cluster-version operator actively managing this resource. Upon update, the CVO will implicitly enable the Console capability, to avoid orphaning that resource. There's OTA-1039 thinking that some day, we might grow some kind of knob to work around that, but there hasn't been enough interest to get it prioritized. So for today's CVO, you'd need to shard this manifest into two:

  • One for cluster profiles like include.release.openshift.io/hypershift where you knew there couldn't be any Console-less clusters yet, where you could add this Console annotation.
  • Another for cluster profiles like include.release.openshift.io/self-managed-high-availability where there might be existing Console-less clusters, where you need to either live with the presence of the resource on clusters without Console enabled, or find some other workaround.

Also in this space, the include.release.openshift.io/single-node-developer profile was abandoned, so you can drop that (e.g. see openshift/cluster-version-operator#685)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You may want to just focus on the Deployment in this pull, and have this StorageVersionMigration manifest be part of OCPBUGS-57055.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi :) why was it decided to merge this PR with this change?
Aren’t we agreed it's needed to keep the profiles separate?

spec:
resource:
group: console.openshift.io
Expand Down
1 change: 1 addition & 0 deletions manifests/07-operator-ibm-cloud-managed.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -3,6 +3,7 @@ apiVersion: apps/v1
kind: Deployment
metadata:
annotations:
capability.openshift.io/name: Console
config.openshift.io/inject-proxy: console-operator
include.release.openshift.io/hypershift: "true"
include.release.openshift.io/ibm-cloud-managed: "true"
Expand Down
1 change: 1 addition & 0 deletions profile-patches/ibm-cloud-managed/07-operator.yaml-patch
Original file line number Diff line number Diff line change
@@ -1,6 +1,7 @@
- op: replace
path: /metadata/annotations
value:
capability.openshift.io/name: Console
config.openshift.io/inject-proxy: console-operator
include.release.openshift.io/hypershift: "true"
include.release.openshift.io/ibm-cloud-managed: "true"
Expand Down