Description of problem: Currently, when the user sets the override on the cluster version using examples like: https://github.com/openshift/cluster-version-operator/blob/master/docs/dev/clusterversion.md#setting-objects-unmanaged CVO stops caring about the objects but it does not provide any information in the status that's actionable on this `upgrade unsupported` scenario. The CVO should atleast set a condition that's set when user creates overrides.
https://github.com/openshift/cluster-version-operator/pull/243 adds upgradeable false when overrides are set.
Since the issue https://github.com/openshift/cluster-version-operator/issues/248, so the https://github.com/openshift/cluster-version-operator/blob/master/docs/dev/clusterversion.md#setting-objects-unmanaged is not workable now to override cvo. Using following file can patch successfully. # cat patch.yaml - op: add path: /spec/overrides value: - kind: Deployment group: apps name: network-operator namespace: openshift-network-operator unmanaged: true # ./oc patch clusterversion version --type json -p "$(cat patch.yaml)" clusterversion.config.openshift.io/version patched So i will verify the bug after the doc updated to ensure correct way used for overrides object in cvo. @Abhinav Dahiya I was told overrides feature was a non-production feature in earlier version(maybe 4.0/4.1). So i need confirm with u that does this feature a production feature now, which means QE will add a case for it.
> https://github.com/openshift/cluster-version-operator/blob/751c6d0c872e05f218f01d2a9f20293b4dfcca88/docs/dev/clusterversion.md#setting-objects-unmanaged provides an example of how to overrides - it shows an manifests that would want to override, _i agree the network operator is a deployment now and not a daemonset but the example is valid in the context_ - it includes the group `apps/v1` > So i will verify the bug after the doc updated to ensure correct way used for overrides object in cvo. So i'm not clear what the blocker for test here?
> So i'm not clear what the blocker for test here? Since the following description briefed me on the verified steps with examples. But the operator in the example does not exist now. So qe need confirm and wait for the correct info to verify it before confirm or doc updated. > Currently, when the user sets the override on the cluster version using examples like: https://github.com/openshift/cluster-version-operator/blob/master/docs/dev/clusterversion.md#setting-objects-unmanaged Now qe will verify the bug according the info in comment4.
Version: 4.3.0-0.nightly-2019-11-17-145435 Steps: 1. install ocp v4.3 cluster 2. patch cv to set network operator unmanaged # ./oc get clusterversion -o json|jq .items[0].spec.overrides [ { "group": "apps/v1", "kind": "Deployment", "name": "network-operator", "namespace": "openshift-network-operator", "unmanaged": true } ] 3. checked the cv status updated. { "lastTransitionTime": "2019-11-18T07:47:53Z", "message": "Disabling ownership via cluster version overrides prevents upgrades. Please remove overrides before continuing.", "reason": "ClusterVersionOverridesSet", "status": "False", "type": "Upgradeable" } 4. due to image check on nightly build, so i have to add "--force" to proceed an upgrade. # ./oc adm upgrade --to 4.3.0-0.nightly-2019-11-17-224250 --force Updating to 4.3.0-0.nightly-2019-11-17-224250 5. checked upgrade result # ./oc get co|grep -v "4.3.0-0.nightly-2019-11-17-224250" NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE dns 4.3.0-0.nightly-2019-11-17-145435 True False False 162m machine-config 4.3.0-0.nightly-2019-11-17-145435 True False False 161m network 4.3.0-0.nightly-2019-11-17-145435 True False False 161m Hi Abhinav Dahiya 1.Due to the image signature for nightly build, so i can not verify if the upgrade can be prevented without "--force", could u check if above verify is enough? 2.According to above result, seems only unmanaged objects set in overrides and some depended objects will be prevented upgrades, so do u think we can enhance the msg to point out which objects will be prevented upgrades. > "message": "Disabling ownership via cluster version overrides prevents upgrades. Please remove overrides before continuing.", This msg seems saying the whole upgrade will be blocked.
> > Hi Abhinav Dahiya > 1.Due to the image signature for nightly build, so i can not verify if the > upgrade can be prevented without "--force", could u check if above verify is > enough? I think this should be enough for this bug as the goal was to make sure user knows the overrides are set and Upgradeable false conditions conveys the message. As for testing if upgrades would require force. you can try to upgrade to a signed release image from https://openshift-release.svc.ci.openshift.org/#4-stable _ make sure you use the digest_ _also note you need to set the flag that allows random upgrade_ This will allow the CVO to verify the release image is okay, and then fail to move forward due to Upgradeable false unless --force is used. Don't wait for upgrade to complete.. as long as it starts we should be good to verify this. > 2.According to above result, seems only unmanaged objects set in overrides > and some depended objects will be prevented upgrades, so do u think we can > enhance the msg to point out which objects will be prevented upgrades. > > "message": "Disabling ownership via cluster version overrides prevents upgrades. Please remove overrides before continuing.", > This msg seems saying the whole upgrade will be blocked. Setting overrides that changes the default management makes Upgrades blocked unless --force . And therefore there is little value in explicitly telling which one. Users shouldn't set Overrides at all and when they do , it's user's responsibility/burden to keep things correct.
(In reply to Abhinav Dahiya from comment #7) > I think this should be enough for this bug as the goal was to make sure user > knows the overrides are set and Upgradeable false conditions conveys the > message. > > As for testing if upgrades would require force. > > you can try to upgrade to a signed release image from > https://openshift-release.svc.ci.openshift.org/#4-stable _ make sure you use > the digest_ _also note you need to set the flag that allows random upgrade_ > This will allow the CVO to verify the release image is okay, and then fail > to move forward due to Upgradeable false unless --force is used. > > Don't wait for upgrade to complete.. as long as it starts we should be good > to verify this. Thx for confirming the verify. For the upgrade without force check, since we do not have 4.3 stable build(with signature) yet from https://openshift-release.svc.ci.openshift.org/#4-stable, and this bug is for 4.3. So it's better to track it after 4.3 release, or we can check it in 4.2 when this bug backport to 4.2. > > Setting overrides that changes the default management makes Upgrades blocked > unless --force . And therefore there is little value in explicitly telling > which one. Users shouldn't set Overrides at all and when they do , it's > user's responsibility/burden to keep things correct. that's ok.
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:0062