Skip to content

Bug 2024433: CustomNoUpgrade should not fire no-upgrade failures#26615

Merged
openshift-merge-robot merged 1 commit intoopenshift:release-4.9from
openshift-cherrypick-robot:cherry-pick-26449-to-release-4.9
Dec 4, 2021
Merged

Bug 2024433: CustomNoUpgrade should not fire no-upgrade failures#26615
openshift-merge-robot merged 1 commit intoopenshift:release-4.9from
openshift-cherrypick-robot:cherry-pick-26449-to-release-4.9

Conversation

@openshift-cherrypick-robot
Copy link
Copy Markdown

This is an automated cherry-pick of #26449

/assign wking

Fixup of 5fb0f99

The commit that is being fixed-up introduced a check against a message
that is not implemented anywhere, thus rendering the function
`isKubeAPIUpgradableNoUpgradeCondition` unusable.

This patch removes the check on the condition message.
@openshift-ci
Copy link
Copy Markdown
Contributor

openshift-ci Bot commented Nov 18, 2021

@openshift-cherrypick-robot: Bugzilla bug 1998029 has been cloned as Bugzilla bug 2024433. Retitling PR to link against new bug.
/retitle [release-4.9] Bug 2024433: CustomNoUpgrade should not fire no-upgrade failures

Details

In response to this:

[release-4.9] Bug 1998029: CustomNoUpgrade should not fire no-upgrade failures

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@openshift-ci openshift-ci Bot changed the title [release-4.9] Bug 1998029: CustomNoUpgrade should not fire no-upgrade failures [release-4.9] Bug 2024433: CustomNoUpgrade should not fire no-upgrade failures Nov 18, 2021
@openshift-ci openshift-ci Bot added the bugzilla/severity-medium Referenced Bugzilla bug's severity is medium for the branch this PR is targeting. label Nov 18, 2021
@openshift-ci
Copy link
Copy Markdown
Contributor

openshift-ci Bot commented Nov 18, 2021

@openshift-cherrypick-robot: This pull request references Bugzilla bug 2024433, which is valid. The bug has been moved to the POST state. The bug has been updated to refer to the pull request using the external bug tracker.

6 validation(s) were run on this bug
  • bug is open, matching expected state (open)
  • bug target release (4.9.z) matches configured target release for branch (4.9.z)
  • bug is in the state NEW, which is one of the valid states (NEW, ASSIGNED, ON_DEV, POST, POST)
  • dependent bug Bugzilla bug 1998029 is in the state CLOSED (CURRENTRELEASE), which is one of the valid states (VERIFIED, RELEASE_PENDING, CLOSED (ERRATA), CLOSED (CURRENTRELEASE))
  • dependent Bugzilla bug 1998029 targets the "4.10.0" release, which is one of the valid target releases: 4.10.0
  • bug has dependents

No GitHub users were found matching the public email listed for the QA contact in Bugzilla (pprinett@redhat.com), skipping review request.

Details

In response to this:

[release-4.9] Bug 2024433: CustomNoUpgrade should not fire no-upgrade failures

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@openshift-ci openshift-ci Bot added the bugzilla/valid-bug Indicates that a referenced Bugzilla bug is valid for the branch this PR is targeting. label Nov 18, 2021
@wking
Copy link
Copy Markdown
Member

wking commented Nov 18, 2021

No need to track the target branch in the PR subject; GitHub tracks that as structured metadata for all PRs.

/retitle Bug 2024433: CustomNoUpgrade should not fire no-upgrade failures

@openshift-ci openshift-ci Bot changed the title [release-4.9] Bug 2024433: CustomNoUpgrade should not fire no-upgrade failures Bug 2024433: CustomNoUpgrade should not fire no-upgrade failures Nov 18, 2021
@openshift-ci openshift-ci Bot requested review from anik120 and hasbro17 November 18, 2021 05:20
@wking
Copy link
Copy Markdown
Member

wking commented Nov 18, 2021

This should fix things like:

  : [sig-arch][Early] Managed cluster should start all core operators [Skipped:Disconnected] [Suite:openshift/conformance/parallel] 
  Run #0: Failed	1s
  fail [github.com/onsi/ginkgo@v4.7.0- 
   origin.0+incompatible/internal/leafnodes/runner.go:113]: Nov 18 03:53:11.275: Some cluster operators are not ready: kube-apiserver (Upgradeable=False FeatureGates_RestrictedFeatureGates_TechPreviewNoUpgrade: FeatureGatesUpgradeable: "TechPreviewNoUpgrade" does not allow updates)

Unsurprisingly, looks like it's perma-failing. Surprisingly, it is unique to 4.9:

$ w3m -dump -cols 200 'https://search.ci.openshift.org/?maxAge=48h&type=junit&search=Some+cluster+operators+are+not+ready.*Upgradeable%3DFalse.*TechPreviewNoUpgrade' | grep 'failures match' | grep -v rehearse | sort
periodic-ci-openshift-release-master-ci-4.9-e2e-aws-techpreview (all) - 8 runs, 100% failed, 75% of failures match = 75% impact
periodic-ci-openshift-release-master-ci-4.9-e2e-aws-techpreview-serial (all) - 8 runs, 100% failed, 100% of failures match = 100% impact
periodic-ci-openshift-release-master-ci-4.9-e2e-azure-techpreview (all) - 8 runs, 100% failed, 88% of failures match = 88% impact
periodic-ci-openshift-release-master-ci-4.9-e2e-azure-techpreview-serial (all) - 8 runs, 100% failed, 50% of failures match = 50% impact
periodic-ci-openshift-release-master-ci-4.9-e2e-openstack-techpreview-parallel (all) - 2 runs, 100% failed, 100% of failures match = 100% impact
periodic-ci-openshift-release-master-ci-4.9-e2e-openstack-techpreview-serial (all) - 2 runs, 100% failed, 100% of failures match = 100% impact

Poking at the 4.9 vs. 4.10 difference:

$ diff -u <(git grep -h10 isKubeAPIUpgradable origin/release-4.9) <(git grep -h10 isKubeAPIUpgradable origin/master)
--- /dev/fd/63  2021-11-17 21:06:02.061366611 -0800
+++ /dev/fd/62  2021-11-17 21:06:02.063366611 -0800
@@ -34,6 +34,5 @@
        return (cond.Reason == "FeatureGates_RestrictedFeatureGates_TechPreviewNoUpgrade" ||
                cond.Reason == "FeatureGates_RestrictedFeatureGates_CustomNoUpgrade") &&
                cond.Status == "False" &&
-               cond.Type == "Upgradeable" &&
-               cond.Message == "FeatureGatesUpgradeable: \"TechPreviewNoUpgrade\" and \"CustomNoUpgrades\" do not allow updates"
+               cond.Type == "Upgradeable"
 }

So that's because:

$ git log --oneline origin/master | grep 'CustomNoUpgrade should not fire'
8b89e16356 CustomNoUpgrade should not fire no-upgrade failures
5fb0f9967c CustomNoUpgrade should not fire no-upgrade failures
$ git log --oneline origin/release-4.9 | grep 'CustomNoUpgrade should not fire'
5fb0f9967c CustomNoUpgrade should not fire no-upgrade failures
$ git log --oneline origin/release-4.8 | grep 'CustomNoUpgrade should not fire'
...no hits...

So 5fb0f99 (#26430) landed in master before 4.9 forked off, but the fixup in 8b89e16 (#26449) missed the cut. This PR picks it back into 4.9.

@LalatenduMohanty
Copy link
Copy Markdown
Member

/lgtm

@openshift-ci openshift-ci Bot added the lgtm Indicates that a PR is ready to be merged. label Nov 18, 2021
cond.Reason == "FeatureGates_RestrictedFeatureGates_CustomNoUpgrade") &&
cond.Status == "False" &&
cond.Type == "Upgradeable" &&
cond.Message == "FeatureGatesUpgradeable: \"TechPreviewNoUpgrade\" and \"CustomNoUpgrades\" do not allow updates"
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.

the point of the string selection is to keep us from allowing techpreview clusters to go upgradeable=false for other reasons. Looks like the string is incorrect?

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.

yes, the point of this conditional is to fail-fast-ish in cases where we are Upgradeable=False for unexpected reasons (it isn't limited to TechPreview). #26449, of which this is a robotic pick, says "you know what, who cares about the Message? (status, type, reason) is enough of a tuple for robots to be confident that this is an allowed reason". If you prefer to also watch over the operator's shoulder and enforce a specific message, I'm... grudgingly ok with that, but can you litigate it in master and then continue with the robotic backports to 4.9?

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.

the point of the string selection is to keep us from allowing techpreview clusters to go upgradeable=false for other reasons

doesn't checking the Reason ensure this, in a more robust(less fragile/subject to change) way?

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.

likely not more robust, but robust enough.

@deads2k
Copy link
Copy Markdown
Contributor

deads2k commented Dec 3, 2021

/approve

@openshift-ci
Copy link
Copy Markdown
Contributor

openshift-ci Bot commented Dec 3, 2021

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: deads2k, LalatenduMohanty, openshift-cherrypick-robot

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-ci openshift-ci Bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Dec 3, 2021
@deads2k deads2k added backport-risk-assessed Indicates a PR to a release branch has been evaluated and considered safe to accept. cherry-pick-approved Indicates a cherry-pick PR into a release branch has been approved by the release branch manager. labels Dec 3, 2021
@openshift-bot
Copy link
Copy Markdown
Contributor

/retest-required

Please review the full test history for this PR and help us cut down flakes.

5 similar comments
@openshift-bot
Copy link
Copy Markdown
Contributor

/retest-required

Please review the full test history for this PR and help us cut down flakes.

@openshift-bot
Copy link
Copy Markdown
Contributor

/retest-required

Please review the full test history for this PR and help us cut down flakes.

@openshift-bot
Copy link
Copy Markdown
Contributor

/retest-required

Please review the full test history for this PR and help us cut down flakes.

@openshift-bot
Copy link
Copy Markdown
Contributor

/retest-required

Please review the full test history for this PR and help us cut down flakes.

@openshift-bot
Copy link
Copy Markdown
Contributor

/retest-required

Please review the full test history for this PR and help us cut down flakes.

@openshift-merge-robot openshift-merge-robot merged commit 4a65e8c into openshift:release-4.9 Dec 4, 2021
@openshift-ci
Copy link
Copy Markdown
Contributor

openshift-ci Bot commented Dec 4, 2021

@openshift-cherrypick-robot: All pull requests linked via external trackers have merged:

Bugzilla bug 2024433 has been moved to the MODIFIED state.

Details

In response to this:

Bug 2024433: CustomNoUpgrade should not fire no-upgrade failures

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

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. backport-risk-assessed Indicates a PR to a release branch has been evaluated and considered safe to accept. bugzilla/severity-medium Referenced Bugzilla bug's severity is medium for the branch this PR is targeting. bugzilla/valid-bug Indicates that a referenced Bugzilla bug is valid for the branch this PR is targeting. cherry-pick-approved Indicates a cherry-pick PR into a release branch has been approved by the release branch manager. lgtm Indicates that a PR is ready to be merged.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants