OTA-1301: WIP: pkg/cincinnati: Set DifferentChannel risk #1059
Conversation
|
@wking: This pull request references OTA-1301 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.17.0" version, but no target version was set. In response to this:
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 openshift-eng/jira-lifecycle-plugin repository. |
openshift-ci-robot
added
the
jira/valid-reference
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: wking 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:
Approvers can indicate their approval by writing |
openshift-ci
bot
added
the
approved
|
Testing a4435fc with Cluster Bot $ oc get -o json clusterversion version | jq .status.desired
{
"image": "registry.build03.ci.openshift.org/ci-ln-slivwqk/release@sha256:9aa335b4a2f6da11e1ef58d0c8fb6f6d1caf4ac5956733facecfd3b87ae3074e",
"version": "4.17.0-0.test-2024-06-19-010126-ci-ln-slivwqk-latest"
}gave me the data to populate OTA-1301's demo graph-data, which I pushed to my graph-data fork. Then I updated my cluster to consume that demo update service: $ oc patch clusterversion version --type json -p '[{"op": "add", "path": "/spec/upstream", "value": "https://raw.githubusercontent.com/wking/cincinnati-graph-data/demo/cincinnati-graph.json"}]'
$ oc adm upgrade channel stable-4.18and I see: $ oc adm upgrade --include-not-recommended
Cluster version is 4.17.0-0.test-2024-06-19-010126-ci-ln-slivwqk-latest
Upstream: https://raw.githubusercontent.com/wking/cincinnati-graph-data/demo/cincinnati-graph.json
Channel: stable-4.18 (available channels: candidate-4.18, fast-4.18, stable-4.18)
Recommended updates:
VERSION IMAGE
4.18.0 quay.io/openshift-release-dev/ocp-release@sha256:0000000000000000000000000000000000000000000000000000000000000000
Supported but not recommended updates:
Version: 4.18.2
Image: quay.io/openshift-release-dev/ocp-release@sha256:2222222222222222222222222222222222222222222222222222222222222222
Recommended: False
Reason: MultipleReasons
Message: A. https://bug.example.com/a
4.18.2 channels (candidate-4.18) do not include this cluster's stable-4.18 https://example.com/FIXME
Version: 4.18.1
Image: quay.io/openshift-release-dev/ocp-release@sha256:1111111111111111111111111111111111111111111111111111111111111111
Recommended: False
Reason: DifferentChannel
Message: 4.18.1 channels (candidate-4.18, fast-4.18) do not include this cluster's stable-4.18 https://example.com/FIXMEHooray, looks good to me. Obviously need to figure out where we want to point the URL, instead of my current https://example.com/FIXME. |
wking
added
the
do-not-merge/work-in-progress
| func differentChannelRisk(release configv1.Release, channel string) configv1.ConditionalUpdateRisk { | ||
| return configv1.ConditionalUpdateRisk{ | ||
| Name: "DifferentChannel", | ||
| URL: "https://example.com/FIXME", // Maybe a KCS? New doc section that we think might be stable between 4.y? Other? |
There was a problem hiding this comment.
This is the bit that needs figuring out still
wking
force-pushed
the
different-channel-risk
branch
2 times, most recently
from
4533796
to
810b42c
Compare
The CVO currently had been assuming all the releases in an Update Service response belong to the currently-configured channel. With this commit, the CVO begins walking retrieved Releases and injecting a DifferentChannel conditional update risk if the current channel is not a member of the Release's channels set. This will allow the CVO to be pointed at an Update Service returning all known (or all supported) next-hop updates, regardless of their current channel, which would make it easier for cluster administrators to self-serve answers like "why don't I see updates to 4.y.z in stable-4.y?" with "oh, because that target is only in candidate-4.y and fast-4.y so far".
wking
force-pushed
the
different-channel-risk
branch
from
810b42c
to
da7ad73
Compare
|
/test unit |
|
@wking: The following tests failed, say
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. |
The CVO currently had been assuming all the releases in an Update Service response belong to the currently-configured channel. With this commit, the CVO begins walking retrieved Releases and injecting a DifferentChannel conditional update risk if the current channel is not a member of the Release's channels set. This will allow the CVO to be pointed at an Update Service returning all known (or all supported) next-hop updates, regardless of their current channel, which would make it easier for cluster administrators to self-serve answers like "why don't I see updates to 4.y.z in
stable-4.y?" with "oh, because that target is only incandidate-4.yandfast-4.yso far".