Skip to content

Commit

Permalink
Revert "blocked-edges/4.7.4*: Targeted edge blocking and version 1.1.0"
Browse files Browse the repository at this point in the history
  • Loading branch information
sdodson authored Sep 21, 2021
1 parent c7820dc commit da1254a
Show file tree
Hide file tree
Showing 6 changed files with 8 additions and 61 deletions.
29 changes: 2 additions & 27 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -98,27 +98,9 @@ declaring that, while 4.1.18 and 4.1.20 are in `candidate-4.2`, they should not
### Block Edges

Create/edit an appropriate file in `blocked_edges/`.

* `to` (required, [string][json-string]) is the release which has the existing incoming edges.
* `from` (required, [string][json-string]) is a regex for the previous release versions.
- `to` is the release which has the existing incoming edges.
- `from` is a regex for the previous release versions.
If you want to require `from` to match the full version string (and not just a substring), you must include explicit `^` and `$` anchors.
Release version strings will receive [the architecture-suffix](#release-names) before being compared to this regular expression.
* `url` (optional, [string][json-string]), with a URI documenting the blocking reason.
For example, this could link to a bug's impact statement or knowledge-base article.
* `name` (optional, [string][json-string]), with a CamelCase reason suitable for [a `ClusterOperatorStatusCondition` `reason` property][api-reason].
* `message` (optional, [string][json-string]), with a human-oriented message describing the blocking reason, suitable for [a `ClusterOperatorStatusCondition` `message` property][api-message].
* `matchingRules` (optional, [array][json-array]), defining conditions for deciding which clusters have the update recommended and which do not.
The array is ordered by decreasing precedence.
Consumers should walk the array in order.
For a given entry, if a condition type is unrecognized, or fails to evaluate, consumers should proceed to the next entry.
If a condition successfully evaluates (either as a match or as an explicit does-not-match), that result is used, and no further entries should be attempted.
If no condition can be successfully evaluated, the update should not be recommended.
Each entry must be an [object][json-object] with at least the following property:

* `type` (required, [string][json-string]), defining the type in [the condition type registry][cluster-condition-type-registry].
For example, `type: promql` identifies the condition as [the `promql` type][cluster-condition-type-registry-promql].

Additional properties for each entry are defined in [the cluster-condition type registry][cluster-condition-type-registry].

For example: to block all incoming edges to a release create a file such as `blocked-edges/4.2.11.yaml` containing:

Expand All @@ -136,17 +118,10 @@ from: ^4\.1\.(18|20)[+].*$

The `[+].*` portion absorbs [the architecture-suffix](#release-names) from the release name that consumers will use for comparisons.

[api-message]: https://github.com/openshift/api/blob/67c28690af52a69e0b8fa565916fe1b9b7f52f10/config/v1/types_cluster_operator.go#L135-L139
[api-reason]: https://github.com/openshift/api/blob/67c28690af52a69e0b8fa565916fe1b9b7f52f10/config/v1/types_cluster_operator.go#L131-L133
[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/
[cluster-condition-type-registry]: https://github.com/openshift/enhancements/pull/821#FIXME
[cluster-condition-type-registry-promql]: https://github.com/openshift/enhancements/pull/821#FIXME
[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
[json-array]: https://datatracker.ietf.org/doc/html/rfc8259#section-5
[json-object]: https://datatracker.ietf.org/doc/html/rfc8259#section-4
[json-string]: https://datatracker.ietf.org/doc/html/rfc8259#section-7
[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
9 changes: 0 additions & 9 deletions blocked-edges/4.7.4-auth-connection-leak.yaml

This file was deleted.

12 changes: 0 additions & 12 deletions blocked-edges/4.7.4-vsphere-hw-17-cross-node-networking.yaml

This file was deleted.

12 changes: 0 additions & 12 deletions blocked-edges/4.7.4-zz-vsphere-hostnames-changing.yaml

This file was deleted.

5 changes: 5 additions & 0 deletions blocked-edges/4.7.4.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,5 @@
to: 4.7.4
from: .*
# 4.7.4 introduced a node-hostname clear on vSphere: https://bugzilla.redhat.com/show_bug.cgi?id=1942207
# 4.7 has cross-node SDN issues on vSphere Virtual Hardware Version 14 and later: https://bugzilla.redhat.com/show_bug.cgi?id=1935539
# Authentication operator's endpoints controller fails to close connections, causing intermittent apiserver and authentication cluster operator instability and high memory usage by the router. A regression since 4.6, eventually fixed in 4.7.11 https://bugzilla.redhat.com/show_bug.cgi?id=1941840
2 changes: 1 addition & 1 deletion version
Original file line number Diff line number Diff line change
@@ -1 +1 @@
1.1.0
1.0.0

0 comments on commit da1254a

Please sign in to comment.