Backfill stable-4.2 nodes into stable-4.3, block 4.3.1 #116
Conversation
|
/cc @wking |
openshift-ci-robot
added
the
size/S
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: sdodson The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
| @@ -1,9 +1,27 @@ | |||
| name: stable-4.3 | |||
There was a problem hiding this comment.
I'm generally not in favor of backfilling (would you include all of stable-4.1 too?), and would rather folks who are this relaxed use version-agnostic channels (#112). But however we do this, we don't want releases in a stable channel that are not in the corresponding fast channel, etc., so you'll want to add the new releases to fast-4.3 and candidate-4.3 as well.
There was a problem hiding this comment.
Yes, I think version agnostic channels would be preferred but that's too big of a change to make without more consideration from the architects team.
The main thing here is we have around 30 clusters in stable-4.3 and have for a few weeks because people've been anticipating a 4.3 upgrade any day now. Most of those clusters are not on 4.2.21 yet so they'd have to go back to stable-4.2 upgrade to 4.2.21 and switch back with out backfilling, correct?
There was a problem hiding this comment.
Most of those clusters are not on 4.2.21 yet so they'd have to go back to stable-4.2 upgrade to 4.2.21 and switch back with out backfilling, correct?
Yup. But we alert on VersionNotFound, right (I hope ;)? If we don't, we should. So folks interested in jumping to 4.3 from earlier 4.2 should have changed their channel to stable-4.3, immediately seen the alert and/or RetrievedUpdates go False, and then changed back to whatever they were on before.
| # someone is on it | ||
| - 4.2.11 | ||
| - 4.2.12 | ||
| - 4.2.13 |
There was a problem hiding this comment.
When adding these to candidate-4.3 (which you should do in this PR), you should also add a blocked-edges/4.3.0-rc.0 to exclude .*, so we don't get a 4.2.13 -> 4.3.0-rc.0 in the candidate graph. And a blocked-edges/4.3.0-rc.3 to exclude 4\.2\.16, because it's easy enough for those folks to flow down 4.2.z and jump off to 4.3 along a later, already stable, edge. Edges into 4.3:
$ for RC in 0 3; do oc adm release info "quay.io/openshift-release-dev/ocp-release:4.3.0-rc.${RC}-x86_64" | grep Upgrade; done
Upgrades: 4.2.13
Upgrades: 4.2.16, 4.3.0-rc.0, 4.3.0-rc.1, 4.3.0-rc.2
$ for z in $(seq 0 5); do oc adm release info "quay.io/openshift-release-dev/ocp-release:4.3.${z}-x86_64" | grep Upgrade; done
Upgrades: 4.2.16, 4.3.0-rc.0, 4.3.0-rc.1, 4.3.0-rc.2, 4.3.0-rc.3
Upgrades: 4.2.18, 4.3.0-rc.0, 4.3.0-rc.3, 4.3.0
Upgrades: 4.2.19, 4.3.0, 4.3.1
Upgrades: 4.2.20, 4.3.0, 4.3.1, 4.3.2
error: image does not exist
Upgrades: 4.2.21, 4.2.22, 4.3.0, 4.3.1, 4.3.2, 4.3.3So the other 4.2 sources are all in this stable-4.3 file already.
There was a problem hiding this comment.
I'm not that concerned about candidate continuity but I think we should explore adding CI to ensure that stable-4.x is a subgraph of fast-4.x which is a subgraph of candidate-4.x.
There was a problem hiding this comment.
I think we should explore adding CI to ensure that stable-4.x is a subgraph of fast-4.x which is a subgraph of candidate-4.x.
There's an open (internal) ticket for that.
This ensures that those who switched to stable-4.3 with hopes of upgrading to 4.3 but before 4.2.21 will be presented upgrades which will eventually lead to 4.3.5 even though they're on a release that doesn't currently upgrade to 4.3.5.
|
/cc @eparis |
|
/close |
|
@sdodson: Closed this PR. DetailsIn 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 kubernetes/test-infra repository. |
3 participants
This ensures that those who switched to stable-4.3 with hopes of upgrading to
4.3 but before 4.2.21 will be presented upgrades which will eventually lead to
4.3.5 even though they're on a release that doesn't currently upgrade to 4.3.5.