-
Notifications
You must be signed in to change notification settings - Fork 4.8k
OTA-1580: Add basic test for oc adm upgrade status CLI
#29954
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
Merged
openshift-merge-bot
merged 1 commit into
openshift:main
from
petr-muller:ota-1580-test-oc-adm-upgrade-status
Jul 22, 2025
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,6 @@ | ||
| # See the OWNERS docs: https://git.k8s.io/community/contributors/guide/owners.md | ||
|
|
||
| approvers: | ||
| - cluster-version-operator-test-case-approvers | ||
| reviewers: | ||
| - cluster-version-operator-test-case-reviewers |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,24 @@ | ||
| package adm_upgrade | ||
|
|
||
| import ( | ||
| g "github.com/onsi/ginkgo/v2" | ||
| o "github.com/onsi/gomega" | ||
| exutil "github.com/openshift/origin/test/extended/util" | ||
| "k8s.io/kubernetes/test/e2e/framework" | ||
| ) | ||
|
|
||
| var _ = g.Describe("[sig-cli][OCPFeatureGate:UpgradeStatus] oc adm upgrade status", func() { | ||
| defer g.GinkgoRecover() | ||
|
|
||
| f := framework.NewDefaultFramework("oc-adm-upgrade-status") | ||
| f.SkipNamespaceCreation = true | ||
|
|
||
| oc := exutil.NewCLIWithoutNamespace("oc-adm-upgrade-status").AsAdmin() | ||
|
|
||
| g.It("reports correctly when the cluster is not updating", func() { | ||
| cmd := oc.Run("adm", "upgrade", "status").EnvVar("OC_ENABLE_CMD_UPGRADE_STATUS", "true") | ||
| out, err := cmd.Output() | ||
| o.Expect(err).NotTo(o.HaveOccurred()) | ||
| o.Expect(out).To(o.Equal("The cluster is not updating.")) | ||
| }) | ||
| }) | ||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
2 changes: 2 additions & 0 deletions
2
test/extended/util/annotate/generated/zz_generated.annotations.go
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Oops, something went wrong.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.
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.
I'm conflicted about the
[OCPFeatureGate:UpgradeStatus]tag. On the one hand, thestatussubcommand is tech-preview. And theUpgradeStatusfeature gate exists, although it's not all that clear in #1725 whether it's trying to cover theoc-side unctionality or the planned-but-abandoned server-side APIs (openshift/enhancements#1701). Using theUpgradeStatusgate to enable this test keeps us from failing default-feature-set CI if the test starts failing, and failing default-feature-set CI on a tech-preview feature isn't desired.On the other hand, our docs point out that you can run the tech-preview
statussubcommand against a default-feature-set cluster:and as your
EnvVarcall in the test shows, the knob that enables thestatussubcommand is theOC_ENABLE_CMD_UPGRADE_STATUSenvironment variable in theocprocess, not theUpgradeStatusfeature-gate in the clusterocis connecting to. And we want CI coverage to verify we're delivering the functionality our docs claim we're delivering. But we don't currently have a CI bucket for "here's some tech-preview client-side stuff we want to confirm works against default-feature-set clusters", and it's not clear if there's enough demand to be worth creating that kind of CI flavor. So which of these options do we like most?a.
[OCPFeatureGate:UpgradeStatus]gating here. Only test the tech-previewocsubcommand against tech-preview clusters. Expose ourselves to regressions using the tech-previewocagainst default-feature-gate clusters, even though we doc that as supported.b. No
OCPFeatureGategating here. Potentially break default-feature-gate CI if this tech-preview functionality acts up. Also maybe miss the API-approver tooling that uses this as a marker of whether the feature is GA-ready?c. Build a new CI flavor that understands how to test tech-preview client-side functionality against a default-feature-gate cluster, in a way compatible with API-approver tooling around deciding if a feature is GA-ready.
None of those sound awesome to me, but given the stability I think we can deliver for this particular subcommand, I think I currently prefer (b), if we can find some way to convince API-approvers that the passing test results mean we're GA-ready, even though we aren't using the
OCPFeatureGatetest-case naming they'd been used to. I'd also be happy with (c), if someone was able to wave a wand and deliver it for free 😄 , but I'm guessing that delivering it would be non-trivial work.I also don't think this needs to block merging. We can pivot between strategies as we go, if we decide to reevaluate the weighting of the different options.
Uh oh!
There was an error while loading. Please reload this page.
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.
Not knowing the super details of Trevor's concern about using [OCPFeatureGate:UpgradeStatus], but do I understand correctly that this UpgradeStatus might not be the most accurate FG to use for this test? If so, and in case this FG graduates to default in the future, this test will start running against the default-feature-set cluster (given the removal of the FG), and we might all of sudden start testing new scenarios (FG test against default-feature-set)? Will that be the risk if we just let PR go as it is? TRT has no problem of approving this if the dev team lgtm it. But we need to understand the situation and dev team's decision. Also, as Trevor pointed out, we know that we are not testing something we are advertising (FG test against default-feature-set).
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.
It has a bit of a history:
UpgradeStatusfeature gate was created for the development of UpdateStatus API in 4.16UpdateStatusgate lost its original purpose of shipping an API, its name fits and I may as well use it as a "promotion vehicle" because it has no other purpose. Its promotion equals this CLI promotion.UpgradeStatuspromotion changes no other behavior in the cluster currently: all that functionality was already removed (there's one very small exception which we track in OTA-1578 which we know has to be removed before the promotion and track it that way).The ideal outcome is the feature gets promoted and then we do not have the TP / Default skew anymore. If I could set up the jobs to exercise this easily (while still feeding into the promotion process) I would do so but there seems to be no way to do so. And while the TP/Default skew is a risk in theory, there is no known reason why it should be a large risk because the API surface to which the CLI is sensitive is all old stable apis and we use no server-side TP features.
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.
Thanks for the explanation! This situation is indeed unique.