Skip to content

Conversation

@sosiouxme
Copy link
Member

No description provided.

@openshift-ci-robot openshift-ci-robot added the size/XS Denotes a PR that changes 0-9 lines, ignoring generated files. label Feb 5, 2020
@eparis
Copy link
Member

eparis commented Feb 5, 2020

/approve

@wking
Copy link
Member

wking commented Feb 5, 2020

Do we also want to add the 4.2 update source? Looks like that's 4.2.18:

$ oc adm release info quay.io/openshift-release-dev/ocp-release:4.3.1-x86_64 | grep Upgrades
  Upgrades: 4.2.18, 4.3.0-rc.0, 4.3.0-rc.3, 4.3.0

I'm also fine if we want to punt putting 4.2.18 into candidate-4.3 to a separate PR.

@openshift-ci-robot openshift-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Feb 5, 2020
@vrutkovs
Copy link

vrutkovs commented Feb 5, 2020

Do we also want to add the 4.2 update source?

I don't think we had sufficient amount of upgrades in fast-4.3 for that yet

I was confused by the channel chain we're using. I'm fine with adding 4.2 builds in candidate

@wking
Copy link
Member

wking commented Feb 6, 2020

Looking through our CI updates, everything looks good except for:

@wking
Copy link
Member

wking commented Feb 6, 2020

Azure failure was probably due to slow disks. Tracked in rhbz#1798785. That's neither new nor update-specific, so my only remaining concerns with this channel promotion are:

Once we get the story around 4.2.18's existence straightened out, the update folks are fine with this.

@wking
Copy link
Member

wking commented Feb 6, 2020

All three replacement 4.2.18 -> 4.3.1 Azure jobs passed, so that's a good sign too.

@sosiouxme
Copy link
Member Author

going to retry 4.2.18
I was thinking that when a release's promotion is successful, that's when we would add a PR just for that release (so in this case, once 4.2.18 is accepted, add it to candidate-4.2 and candidate-4.3). Makes our logic simpler not to have to think about multiple releases. Can OTA just add blocked edges to our PRs as they see fit?

@LalatenduMohanty
Copy link
Member

Can OTA just add blocked edges to our PRs as they see fit?

OTA wont be merging any PRs as it is up to the release admins. But OTA would provide info with respect to, if the edge looks stable enough by looking in to telemetry dash boards and CI results.

…consider

4.2.18 is baked into 4.3.1 as a recommended update source, but we
don't have a 4.2.18 release yet.  Block until we have a release, to
avoid accidentally adding 4.2.18 -> 4.3.1 to channels if 4.2.18 ends
up being a dud.
@wking
Copy link
Member

wking commented Feb 6, 2020

Can OTA just add blocked edges to our PRs as they see fit?

I've pushed 060341c -> 9c77b39 to your branch for this PR blocking 4.2.18->4.3.1 until we have a 4.2.18 to consider. Generated with:

$ git remote add sosiouxme ssh://github.com/sosiouxme/cincinnati-graph-data.git
$ git fetch sosiouxme
$ git checkout sosiouxme/patch-3
$ emacs blocked-edges/4.3.1.yaml  # manually fill this in
$ git add blocked-edges/4.3.1.yaml
$ git commit -v
$ git push sosiouxme HEAD:patch-3

@eparis
Copy link
Member

eparis commented Feb 6, 2020

/lgtm

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Feb 6, 2020
@openshift-ci-robot
Copy link

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: eparis, sosiouxme

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-merge-robot openshift-merge-robot merged commit ec0a82b into openshift:master Feb 6, 2020
wking referenced this pull request in wking/cincinnati-graph-data Feb 20, 2020
The release has been in the candidate analogs since 6ed3a35
(candidate-4.2: add 4.2.18, 2020-02-12, #49), which is plenty of cook
time.

Also, now that we have a 4.2.18, we can drop the blocked edge from
9c77b39 (blocked-edges/4.3.1: Block 4.2.18 -> 4.3.1 until we have a
4.2.18 to consider, 2020-02-06, #43).  Would have been nice if that
had happened in 6ed3a35, but better late than never ;).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged. size/XS Denotes a PR that changes 0-9 lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants