Skip to content

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.

Sign up for GitHub

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

Merged
openshift-merge-robot merged 24 commits into from
Apr 28, 2021
Merged

channels: Add 'feeder' and 'tombstones' properties #75

Show file tree
Hide file tree
Changes from 2 commits
Commits
Show all changes
24 commits
Select commit Hold shift + click to select a range
2a789eb
README: "Release names" -> "Release Names"
wking Feb 24, 2020
ea770af
channels: Add a 'feeder' property
wking Feb 24, 2020
0827519
hack/stabilization-changes: Use 'git blame' to recommend auto-stabili…
wking Feb 25, 2020
c1f917a
channels: Add a 'tombstones' property
wking Feb 25, 2020
04421c6
README: Add a note about future phased release rollouts
wking Feb 26, 2020
3aa0cc9
channels: Tombstone 4.1.37
wking Mar 11, 2020
4fb7a0e
channels/fast-*: Bump delay to one week
wking Apr 7, 2020
371881d
channels/candidate: Tombstone 4.3.11
wking Apr 15, 2020
9d1f15f
channels/candidate-4.[34]: Tombstone 4.3.14, 4.3.15, and 4.3.16
wking Apr 27, 2020
1e70c71
channels/candidate-4.[2345]: Tombstone 4.2.30, 4.2.32, 4.3.17, 4.4.0-…
wking May 8, 2020
38c3869
channels/candidate-4.[345]: Tombstone 4.3.24 and 4.4.7
wking Jul 1, 2020
fe865de
channels/stable: Delay stable 48h beyond fast
wking Apr 1, 2021
0895816
channels/candidate-4.[45]: Tombstone 4.4.22
wking Apr 1, 2021
e8a9f82
channels/candidate-4.[45]: Tombstone 4.4.24 and 4.4.25
wking Apr 1, 2021
e7bbe4e
channels/candidate-4.[45]: Tombstone 4.4.28
wking Apr 1, 2021
d508cbd
channels/candidate-4.[56]: Tombstone 4.5.0
wking Apr 1, 2021
2102bb6
channels/candidate-4.[56]: Tombstone 4.5.0-0.hotfix-2020-11-28-021842
wking Apr 1, 2021
e315a69
channels/candidate-4.[56]: Tombstone 4.5.25, 4.5.29, and 4.5.32
wking Apr 1, 2021
96f3b53
channels/candidate-4.6: Tombstone 4.6.0 and 4.6.2
wking Apr 1, 2021
3572df2
channels/candidate-4.6: Tombstone 4.6.5
wking Apr 1, 2021
ffd85a2
channels/candidate-4.6: Tombstone 4.6.7
wking Apr 1, 2021
079da51
channels/candidate-4.[67]: Tombstone 4.6.10
wking Apr 1, 2021
845ac82
channels/stable-4.5: Promote 4.5.10 and 4.5.12
wking Apr 1, 2021
8265e89
channels/candidate-4.[67]: Tombstone 4.6.24 on registry CA handling
wking Apr 13, 2021
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
33 changes: 29 additions & 4 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand All @@ -31,13 +31,36 @@ 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).

@LalatenduMohanty LalatenduMohanty Feb 25, 2020

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

s/would/need to/

@wking wking Feb 25, 2020

Copy link
Copy Markdown
Member Author

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?


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`.
Comment thread
wking marked this conversation as resolved.

In this repository, the intended promotion flow is reflected by a `feeder` property in the channel declaration.

@steveej steveej Feb 26, 2020

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Do we still need the feeder property if we reduce the chain to being candidate --> stable?

@vrutkovs vrutkovs Mar 11, 2020

Copy link
Copy Markdown

Choose a reason for hiding this comment

The 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

@wking wking Mar 12, 2020

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Do we still need the feeder property if we reduce the chain to being candidate --> stable?

We also have prerelease -> stable for 4.1. And we could theoretically also make a plural feeders and have multiple candidate-4.* feeding into candidate (#112). I like this being explicit, but don't really care if folks would rather bake the feeder directions into the recommending script (currently the stabilization-changes subcommand) instead of tracking it in the channel YAML.

For example, for [`channels/fast-4.2.yaml`](channels/fast-4.2.yaml):

```yaml
feeder:
name: candidate-4.2
delay: PT24H
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 24 hours 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`.

@LalatenduMohanty LalatenduMohanty Feb 25, 2020

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

@steveej steveej Feb 26, 2020

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The 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?

@wking wking Mar 12, 2020

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

By which automation is this delay used...

By a periodic that runs stabilization-changes and creates PRs for any recommended promotions. Then eventually, when we trust our automatic edge-pulling, we give the robot creds to approve their own PRs so they will auto-merge.

... and how would one override it?

Manually create pull requests if you don't want to wait the configured delay?

@jwforres jwforres Mar 17, 2020

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The 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

@wking wking Apr 28, 2021

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

### Block Edges

Create/edit an appropriate file in `blocked_edges/`.
Expand All @@ -59,5 +82,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
4 changes: 4 additions & 0 deletions channels/eus-4.6.yaml
View file
Open in desktop
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
Expand Down
4 changes: 4 additions & 0 deletions channels/fast-4.2.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,4 +1,8 @@
name: fast-4.2
feeder:
name: candidate-4.2
delay: PT24H
filter: 4\.[0-9]+\.[0-9]+(.*hotfix.*|\+amd64|-s390x)?
versions:
- 4.1.20
- 4.1.21
Expand Down
4 changes: 4 additions & 0 deletions channels/fast-4.3.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,4 +1,8 @@
name: fast-4.3
feeder:
name: candidate-4.3

@jwforres jwforres Mar 17, 2020

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The 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)

@wking wking Mar 17, 2020

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The 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)

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 candidate channel from the proposal in #112. And that's going to be a bit tricky because of the possibility of implicit edge blocking as discussed in #112, so I haven't dipped into that here. Can we punt on it and revisit if/when we get around to considering #112? Or should we hash it out in this PR?

delay: PT24H
filter: 4\.[0-9]+\.[0-9]+(.*hotfix.*)?
versions:
- 4.2.36
- 4.2.34
Expand Down
4 changes: 4 additions & 0 deletions channels/fast-4.4.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,4 +1,8 @@
name: fast-4.4
feeder:
name: candidate-4.4
delay: PT24H
filter: 4\.[0-9]+\.[0-9]+(.*hotfix.*)?
versions:
- 4.3.40
- 4.3.38
Expand Down
4 changes: 4 additions & 0 deletions channels/fast-4.5.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,4 +1,8 @@
name: fast-4.5
feeder:
name: candidate-4.5
delay: PT24H
Comment thread
wking marked this conversation as resolved.
Outdated
filter: 4\.[0-9]+\.[0-9]+(.*hotfix.*)?
versions:
- 4.4.33

Expand Down
4 changes: 4 additions & 0 deletions channels/fast-4.6.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,4 +1,8 @@
name: fast-4.6
feeder:
name: candidate-4.6
delay: PT24H
filter: 4\.[0-9]+\.[0-9]+(.*hotfix.*)?
versions:
- 4.5.37

Expand Down
4 changes: 4 additions & 0 deletions channels/fast-4.7.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,4 +1,8 @@
name: fast-4.7
feeder:
name: candidate-4.7
delay: PT24H
filter: 4\.[0-9]+\.[0-9]+(.*hotfix.*)?
versions:
- 4.6.23
- 4.6.22
Expand Down
6 changes: 6 additions & 0 deletions channels/fast-4.8.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,6 @@
name: fast-4.8
feeder:
name: candidate-4.8
delay: PT24H
filter: 4\.[0-9]+\.[0-9]+(.*hotfix.*)?
versions: []
4 changes: 4 additions & 0 deletions channels/stable-4.1.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,4 +1,8 @@
name: stable-4.1
feeder:
name: prerelease-4.1
delay: PT24H
filter: 4\.[0-9]+\.[0-9]+(.*hotfix.*)?
versions:
- 4.1.0
- 4.1.1
Expand Down
3 changes: 3 additions & 0 deletions channels/stable-4.2.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,4 +1,7 @@
name: stable-4.2
feeder:
name: fast-4.2
delay: PT24H
versions:
- 4.1.20
- 4.1.21
Expand Down
3 changes: 3 additions & 0 deletions channels/stable-4.3.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,4 +1,7 @@
name: stable-4.3
feeder:
name: fast-4.3
delay: PT24H
versions:
- 4.2.36
- 4.2.34
Expand Down
3 changes: 3 additions & 0 deletions channels/stable-4.4.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,4 +1,7 @@
name: stable-4.4
feeder:
name: fast-4.4
delay: PT24H
versions:
- 4.3.40
- 4.3.38
Expand Down
3 changes: 3 additions & 0 deletions channels/stable-4.5.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,4 +1,7 @@
name: stable-4.5
feeder:
name: fast-4.5
delay: PT24H
Comment thread
wking marked this conversation as resolved.
Outdated
versions:
- 4.4.33

Expand Down
3 changes: 3 additions & 0 deletions channels/stable-4.6.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,4 +1,7 @@
name: stable-4.6
feeder:
name: fast-4.6
delay: PT24H
versions:
- 4.5.36
- 4.5.35
Expand Down
3 changes: 3 additions & 0 deletions channels/stable-4.7.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,4 +1,7 @@
name: stable-4.7
feeder:
name: fast-4.7
delay: PT24H
versions:
- 4.6.23
- 4.6.22
Expand Down
5 changes: 5 additions & 0 deletions channels/stable-4.8.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,5 @@
name: stable-4.8
feeder:
name: fast-4.8
delay: PT24H
versions: []