-
Notifications
You must be signed in to change notification settings - Fork 65
Backfill stable-4.2 nodes into stable-4.3, block 4.3.1 #116
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,3 @@ | ||
| to: 4.3.1 | ||
| from: 4\.2\..* | ||
| # 4.2 -> 4.3 was not deemed stable until 4.3.5 |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,14 +1,31 @@ | ||
| name: stable-4.3 | ||
| versions: | ||
| # 4.2.16+amd64 - withheld as it's only valid into 4.3.0,4.3.1 people should go direct to 4.3.5 | ||
| - 4.2.0 | ||
| - 4.2.1 | ||
| - 4.2.2 | ||
| # no 4.2.3 because it was rolled into 4.2.4 | ||
| - 4.2.4 | ||
| # no 4.2.5 because it was cut missing some intended update sources | ||
| # no 4.2.6 because it pulled in CI-built images due to due to release job modification for multi-arch | ||
| - 4.2.7 | ||
| - 4.2.8 | ||
| - 4.2.9 | ||
| - 4.2.10 | ||
| # - 4.2.11 failed to run tests, we never officially released it, but we accidentally | ||
| # put it in a channel! (same for s390x) Now we shouldn't pull it, just in case | ||
| # someone is on it | ||
| - 4.2.11 | ||
| - 4.2.12 | ||
| - 4.2.13 | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. When adding these to $ 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.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not that concerned about candidate continuity but I think we should explore adding CI to ensure that
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
There's an open (internal) ticket for that. |
||
| - 4.2.14+amd64 | ||
| - 4.2.16+amd64 | ||
| # not 4.2.17 because we had a long quiet time after 4.2.16 with no releases | ||
sdodson marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| # 4.2.18+amd64 - withheld as it's only valid into 4.3.1, people should go direct to 4.3.5 | ||
| # 4.2.19+amd64 - withheld as it's only valid into 4.3.1, people should go direct to 4.3.5 | ||
| - 4.2.18+amd64 | ||
| - 4.2.19+amd64 | ||
| - 4.2.20+amd64 | ||
| - 4.2.21+amd64 | ||
| # until s390 is released on 4.3 we may not want to include it in 4.3 channels | ||
| # 4.2 -> 4.3 updates occasionally hit RequiredPoolsFailed, fixed in 4.2.18 and rc.0, but not in 4.2.16: https://bugzilla.redhat.com/show_bug.cgi?id=1782152 https://bugzilla.redhat.com/show_bug.cgi?id=1782149 | ||
| # not 4.2.17 because we had a long quiet time after 4.2.16 with no releases | ||
| # 4.2.21 edge into stable-4.3 pending further review | ||
| - 4.3.0 | ||
| - 4.3.1 | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.3andcandidate-4.3as well.Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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/orRetrievedUpdatesgoFalse, and then changed back to whatever they were on before.