-
Notifications
You must be signed in to change notification settings - Fork 65
channels: Add 'feeder' and 'tombstones' properties #75
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
2a789eb
ea770af
0827519
c1f917a
04421c6
3aa0cc9
4fb7a0e
371881d
9d1f15f
1e70c71
38c3869
fe865de
0895816
e8a9f82
e7bbe4e
d508cbd
2102bb6
e315a69
96f3b53
3572df2
ffd85a2
079da51
845ac82
8265e89
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 |
|---|---|---|
|
|
@@ -13,14 +13,14 @@ The [contributing documentation](CONTRIBUTING.md) covers licencing and the usual | |
|
|
||
| [Cincinnati][] is configured to track the master branch, so it will automatically react to updates made to this repository. | ||
|
|
||
| ### Schema version | ||
| ### Schema Version | ||
|
|
||
| The layout of this repository is versioned via [a `version` file](version), which contains the [Semantic Version][semver] of the schema. | ||
| As a schema version, the patch level is likely to remain 0, but the minor version will be incremented if backwards-compatible features are added, and the major version will be incremented if backwards-incompatible changes are made. | ||
| Consumers, such as [Cincinnati][], who support *x.y.0* may safely consume this repository when the stated major version matches the understood *x* and the stated minor version is less than or equal to the understood *y*. | ||
| For example, a consumer that supports 1.3.0 and 2.1.0 could safely consume 1.2.0, 1.3.0, 2.0.0, 2.1.0, etc., but could not safely consume 1.4.0, 2.2.0, 3.0.0, etc. | ||
|
|
||
| ### Release names | ||
| ### Release Names | ||
|
|
||
| Release names are used for [adding releases to channels](#add-releases-to-channels) and [blocking edges](#block-edges). | ||
| Architecture-agnostic names will apply to all images with that exact name in the `version` property of the `release-metadata` file included in the release image. | ||
|
|
@@ -31,13 +31,60 @@ And 4.2.14+amd64 would only apply to the amd64 release image. | |
| ### Add Releases To Channels | ||
|
|
||
| Edit the appropriate file in `channels/`. | ||
| For example, to add a release to stable-4.2 you would edit `channels/stable-4.2.yaml`. | ||
| Channel semantics are documented [here][channel-semantics]. | ||
| For example, to add a release to candidate-4.2 you would edit [`channels/candidate-4.2.yaml`](channels/candidate-4.2.yaml). | ||
|
|
||
| The file contains a list of versions. | ||
| Please keep the versions in order. | ||
| And LEAVE COMMENTS if you skip a version. | ||
|
|
||
| #### Feeder Channels | ||
|
|
||
| Channel semantics, as documented [here][channel-semantics], show nodes and edges being promoted to successive channels as they prove their stability. | ||
| For example, a 4.2.z release will appear in `candidate-4.2` first. | ||
| Upon proving itself sufficiently stable in the candidate channel, it will be promoted into `fast-4.2`. | ||
| Some time after landing in `fast-4.2`, it will appear in `stable-4.2`. | ||
wking marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| _Note:_ Once we have phased release rollouts, we will drop the fast/stable distinction from this repository and promote to a unified fast/stable channel with a start time and rollout duration. | ||
| Until then, we are using fast channels to feed stable channels with a delay, just like candidate channels feed fast channels. | ||
|
|
||
| In this repository, the intended promotion flow is reflected by a `feeder` property in the channel declaration. | ||
|
Contributor
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. Do we still need the 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 think its still useful, just in case the names would be less clear
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.
We also have prerelease -> stable for 4.1. And we could theoretically also make a plural |
||
| For example, for [`channels/fast-4.2.yaml`](channels/fast-4.2.yaml): | ||
|
|
||
| ```yaml | ||
| feeder: | ||
| name: candidate-4.2 | ||
| delay: P1W | ||
| filter: 4\.[0-9]+\.[0-9]+(.*hotfix.*|\+amd64|-s390x)? | ||
| ``` | ||
|
|
||
| which declares the intention that nodes and edges will be considered for promotion into `fast-4.2` after cooking for one week in `candidate-4.2`. | ||
| The `delay` value is an [ISO 8601][rfc-3339-p13] [duration][iso-8601-durations]. | ||
| The `filter` value excludes `4.2.0-rc.5` and other releases, while allowing for `4.2.0-0.hotfix-2020-09-19-234758` and `4.2.10-s390x` and `4.2.14+amd64`. | ||
|
|
||
|
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. 👍 |
||
| This is the expected delay, but it does not mean that promotion will happen at that moment. | ||
|
Contributor
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. By which automation is this delay used and how would one override it?
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.
By a periodic that runs
Manually create pull requests if you don't want to wait the configured delay?
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. If / when robots were auto-merging these PRs, how would release admins override the bot from promoting something
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. The most important action is ART publishing the errata, which is when a release is declared supported, regardless of what we do in Cincinnati. So you could tombstone a release if you didn't want it auto-promoted. But if the release is only in candidate, you had better also tell ART to not ship the errata. And if the errata has shipped, tombstoning fast or stable promotions won't drop any supported-ness. |
||
| For example, it is possible that release architects decide that there is insufficient data for a `fast-4.2` promotion, in which case the promotion can be delated until sufficient data accumulates. | ||
|
|
||
| To see recommended feeder promotions, run: | ||
|
|
||
| ```console | ||
| $ hack/stabilization-change.py | ||
| ``` | ||
|
|
||
| ##### Tombstones | ||
|
|
||
| Removing a node from a channel can strand existing clusters with a `VersionNotFound` error. | ||
| To avoid that, unstable nodes are left in their existing channels, but should not be promoted to additional channels. | ||
| This is reflected through entries in the optional `tombstones` property. | ||
| For example, [`channels/candidate-4.2.yaml`](channels/candidate-4.2.yaml) has: | ||
|
|
||
| ```yaml | ||
| tombstones: | ||
|
Contributor
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 propose naming it frozen instead of tombstones.
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. @steveej
Contributor
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 think that tombstones doesn't communicate it well either, since these versions are still in use somewhere, which is the reason why we need to give them an additional property. Also, It would be nice to stick to a more technical or neutral term here. How about immobilized? 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 like tombstones more. These builds are similar to ghosts we don't speak of since they are dead to us and we don't want them coming back :)
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. Tombstone has an existing technical usage, which is similar to the usage here. |
||
| - 4.1.18 | ||
| - 4.1.20 | ||
| ``` | ||
|
|
||
| declaring that, while 4.1.18 and 4.1.20 are in `candidate-4.2`, they should not be promoted to subsequent channels (in this case, `fast-4.2`). | ||
|
|
||
| ### Block Edges | ||
|
|
||
| Create/edit an appropriate file in `blocked_edges/`. | ||
|
|
@@ -59,5 +106,7 @@ from: 4\.1\.(18|20) | |
| [channel-semantics]: https://docs.openshift.com/container-platform/4.3/updating/updating-cluster-between-minor.html#understanding-upgrade-channels_updating-cluster-between-minor | ||
| [Cincinnati]: https://github.com/openshift/cincinnati/ | ||
| [image-arch]: https://github.com/opencontainers/image-spec/blame/v1.0.1/config.md#L103 | ||
| [iso-8601-durations]: https://en.wikipedia.org/wiki/ISO_8601#Durations | ||
| [rfc-3339-p13]: https://tools.ietf.org/html/rfc3339#page-13 | ||
| [semver]: https://semver.org/spec/v2.0.0.html | ||
| [semver-build]: https://semver.org/spec/v2.0.0.html#spec-item-10 | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,4 +1,8 @@ | ||
| name: eus-4.6 | ||
| feeder: | ||
| name: stable-4.6 | ||
| delay: PT0H | ||
| filter: 4\.6\.[0-9]+(.*hotfix.*)? | ||
| versions: | ||
| - 4.6.1 | ||
| - 4.6.3 | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,4 +1,8 @@ | ||
| name: fast-4.3 | ||
| feeder: | ||
| name: candidate-4.3 | ||
|
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. how are we handling n-1 minor feeders? both candidate-4.2 and candidate-4.3 feed into fast-4.3 (after we open the minor version upgrades for that release)
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 think only candidate-4.3 feeds fast-4.3. It's just that we add both 4.2 and 4.3 releases to candidate-4.3. There is a potential use-case for having multiple feeders, but I think it's all of the candidate-4.* channels feeding the version-agnostic |
||
| delay: P1W | ||
| filter: 4\.[0-9]+\.[0-9]+(.*hotfix.*)? | ||
| versions: | ||
| - 4.2.36 | ||
| - 4.2.34 | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,4 +1,8 @@ | ||
| name: fast-4.5 | ||
| feeder: | ||
| name: candidate-4.5 | ||
| delay: P1W | ||
| filter: 4\.[0-9]+\.[0-9]+(.*hotfix.*)? | ||
| versions: | ||
| - 4.4.33 | ||
|
|
||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,4 +1,8 @@ | ||
| name: fast-4.6 | ||
| feeder: | ||
| name: candidate-4.6 | ||
| delay: P1W | ||
| filter: 4\.[0-9]+\.[0-9]+(.*hotfix.*)? | ||
| versions: | ||
| - 4.5.37 | ||
|
|
||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,6 @@ | ||
| name: fast-4.8 | ||
| feeder: | ||
| name: candidate-4.8 | ||
| delay: P1W | ||
| filter: 4\.[0-9]+\.[0-9]+(.*hotfix.*)? | ||
| versions: [] |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,4 +1,7 @@ | ||
| name: stable-4.2 | ||
| feeder: | ||
| name: fast-4.2 | ||
| delay: PT48H | ||
| versions: | ||
| - 4.1.20 | ||
| - 4.1.21 | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,4 +1,7 @@ | ||
| name: stable-4.3 | ||
| feeder: | ||
| name: fast-4.3 | ||
| delay: PT48H | ||
| versions: | ||
| - 4.2.36 | ||
| - 4.2.34 | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,4 +1,7 @@ | ||
| name: stable-4.4 | ||
| feeder: | ||
| name: fast-4.4 | ||
| delay: PT48H | ||
| versions: | ||
| - 4.3.40 | ||
| - 4.3.38 | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,4 +1,7 @@ | ||
| name: stable-4.5 | ||
| feeder: | ||
| name: fast-4.5 | ||
| delay: PT48H | ||
| versions: | ||
| - 4.4.33 | ||
|
|
||
|
|
@@ -37,7 +40,9 @@ versions: | |
| - 4.5.7 | ||
| - 4.5.8 | ||
| - 4.5.9 | ||
| - 4.5.10 | ||
|
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. We're retroactively adding those to stable - is this intended?
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. Yeah, see discussion in 845ac82. 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. intended - 845ac82 |
||
| - 4.5.11 | ||
| - 4.5.12 | ||
| - 4.5.13 | ||
| - 4.5.14 | ||
| - 4.5.15 | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,4 +1,7 @@ | ||
| name: stable-4.6 | ||
| feeder: | ||
| name: fast-4.6 | ||
| delay: PT48H | ||
| versions: | ||
| - 4.5.36 | ||
| - 4.5.35 | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,4 +1,7 @@ | ||
| name: stable-4.7 | ||
| feeder: | ||
| name: fast-4.7 | ||
| delay: PT48H | ||
| versions: | ||
| - 4.6.23 | ||
| - 4.6.22 | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,5 @@ | ||
| name: stable-4.8 | ||
| feeder: | ||
| name: fast-4.8 | ||
| delay: PT48H | ||
| versions: [] |
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.
s/would/need to/
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.
preexisting language; file a separate PR?