Skip to content
Closed
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
3 changes: 3 additions & 0 deletions blocked-edges/4.3.1.yaml
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
25 changes: 21 additions & 4 deletions channels/stable-4.3.yaml
Original file line number Diff line number Diff line change
@@ -1,14 +1,31 @@
name: stable-4.3
Copy link
Member

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.3 and candidate-4.3 as well.

Copy link
Member Author

@sdodson sdodson Mar 13, 2020

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?

Copy link
Member

Choose a reason for hiding this comment

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

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.

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
Copy link
Member

Choose a reason for hiding this comment

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

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.3

So the other 4.2 sources are all in this stable-4.3 file already.

Copy link
Member Author

Choose a reason for hiding this comment

The 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 stable-4.x is a subgraph of fast-4.x which is a subgraph of candidate-4.x.

Copy link
Member

Choose a reason for hiding this comment

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

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.

- 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
# 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
Expand Down