Skip to content

Conversation

petr-muller
Copy link
Member

@petr-muller petr-muller commented Jul 23, 2025

OTA uses UpgradeStatus feature gate name to identify the CLI-side functionality described in OTA-1577 (oc adm upgrade status command).

The UpgradeStatus feature gate does not enable any cluster-side functionality (neither API changes or any controller code). The actual functionality will be enabled in oc through openshift/oc#2063. The UpgradeStatus feature gate thus serves only as a vehicle to perform the data-driven promotion decision by tying the appropriate test coverage to this name so that the promotion criteria can be automatically checked.

Therefore, this PR serves as a formal decision record only, and after it merges, it means openshift/oc#2063 is allowed to merge.

@openshift-ci-robot openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Jul 23, 2025
@openshift-ci-robot
Copy link

openshift-ci-robot commented Jul 23, 2025

@petr-muller: This pull request references OTA-1580 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.20.0" version, but no target version was set.

In response to this:

This is a request for an exception in the feature promotion process.

Proposed promotion process:

  1. Promote UpgradeStatus gate here. This does not actually put any functional change into customers' hands.
  2. Promotion will allow tests tagged with UpgradeStatus to run in Default update jobs
  3. Update-time tests will execute and feed results into Sippy feature view
  4. The feature view will need to be monitored manually to meet the criteria otherwise enforced by verify-feature-promotion
  5. Once that happens, actually promote the feature through OTA-1581: Promote oc adm upgrade status to general availability oc#2063

Why is exception needed:

The feature promoted under UpgradeStatus gate identifier is actually entirely client-side implementation of the oc adm upgrade status command. Promoting the feature in o/api has no effect on any functionality in the cluster; nothing reads and depends on this identifier in the cluster (as of Jul 23, with the exception of the about to be removed behavior, tracked in OTA-1578 / openshift/cluster-version-operator#1216 expected to merge soon). The actual "promotion" of the feature would be done in the o/oc repository with a PR such as openshift/oc#2063 (intentionally /hold for now because of its "feature promotion" semantics).

We wanted to utilize the UpgradeStatus gate to pursue the data-driven promotion process, but the process does not seem to accommodate features tied to OCP updates. Features are expected to accumulate test coverage in TechPreview (TP) jobs, but there are no TP jobs that exercise a cluster update. Minor version update TP cannot exist by definition (TechPreviewNoUpgrade). Patch version update jobs can exist in theory, but is likely that OCP cannot realistically maintain such jobs because teams are allowed to make update-breaking changes in TP (such as promotion where a v1alpha1 API will be replaced with a v1 one) until the version is GA. That means update-related features cannot easily accumulate sufficient test data in available TechPreview jobs (we may need to address this gap in the future because the exception process proposed here will not succeed for cluster-side behavior).

For this feature specifically, running in TechPreview jobs would actually increase risk of problems after promotion. The conditional behavior is entirely client-side; testing it against TP clusters carries a risk of inadvertedly depending on some cluster-side TP-only feature. Such feature could be missing in Default clusters and the client-side behavior can break when run against a Default cluster. For CLI-side features, it seems more appropriate to test TP behavior against a Default cluster instead. This is possible, but non-TP jobs will not execute tests tagged with a TP feature gate name such as FeatureGate.

How are regressions prevented:

  • Promoting UpgradeStatus in o/api has no risks because it does not change any behavior except test selection
  • Running candidate CLI behavior against Default clusters actually provides better quality signal than against TP clusters
  • Tests tagged with UpgradeStatus will need better scrutiny before merge because they will run in Default jobs and not just TP jobs
  • The actual promotion in o/oc is still gated by data evidence of passing tests, in spirit with the usual promotion process

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 openshift-eng/jira-lifecycle-plugin repository.

Copy link
Contributor

openshift-ci bot commented Jul 23, 2025

Hello @petr-muller! Some important instructions when contributing to openshift/api:
API design plays an important part in the user experience of OpenShift and as such API PRs are subject to a high level of scrutiny to ensure they follow our best practices. If you haven't already done so, please review the OpenShift API Conventions and ensure that your proposed changes are compliant. Following these conventions will help expedite the api review process for your PR.

@openshift-ci-robot
Copy link

openshift-ci-robot commented Jul 23, 2025

@petr-muller: This pull request references OTA-1580 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.20.0" version, but no target version was set.

In response to this:

This is a request for an exception in the feature promotion process.

Proposed promotion process:

  1. Promote UpgradeStatus gate here. This does not actually put any functional change into customers' hands.
  2. Promotion will allow tests tagged with UpgradeStatus to run in Default update jobs
  3. Update-time tests will execute and feed results into Sippy feature view
  4. The feature view will need to be monitored manually to meet the criteria otherwise enforced by verify-feature-promotion
  5. Once that happens, actually promote the feature through OTA-1581: Promote oc adm upgrade status to general availability oc#2063

Why is exception needed:

The feature promoted under UpgradeStatus gate identifier is actually entirely client-side implementation of the oc adm upgrade status command. Promoting the feature in o/api has no effect on any functionality in the cluster; nothing reads and depends on this identifier in the cluster (as of Jul 23, with the exception of the about to be removed behavior, tracked in OTA-1578 / openshift/cluster-version-operator#1216 expected to merge soon). The actual "promotion" of the feature would be done in the o/oc repository with a PR such as openshift/oc#2063 (intentionally /hold for now because of its "feature promotion" semantics).

We wanted to utilize the UpgradeStatus gate to pursue the data-driven promotion process, but the process does not seem to accommodate features tied to OCP updates. Features are expected to accumulate test coverage in TechPreview (TP) jobs, but there are no TP jobs that exercise a cluster update. Minor version update TP cannot exist by definition (TechPreviewNoUpgrade). Patch version update jobs can exist in theory, but is likely that OCP cannot realistically maintain such jobs because teams are allowed to make update-breaking changes in TP (such as promotion where a v1alpha1 API will be replaced with a v1 one) until the version is GA. That means update-related features cannot easily accumulate sufficient test data in available TechPreview jobs (we may need to address this gap in the future because the exception process proposed here will not succeed for cluster-side behavior).

For this feature specifically, running in TechPreview jobs would actually increase risk of problems after promotion. The conditional behavior is entirely client-side; testing it against TP clusters carries a risk of inadvertedly depending on some cluster-side TP-only feature. Such feature could be missing in Default clusters and the client-side behavior can break when run against a Default cluster. For CLI-side features, it seems more appropriate to test TP behavior against a Default cluster instead. This is possible, but non-TP jobs will not execute tests tagged with a TP feature gate name such as FeatureGate.

How are regressions prevented:

  • Promoting UpgradeStatus in o/api has no risks because it does not change any behavior except test selection
  • Running candidate CLI behavior against Default clusters actually provides better quality signal than against TP clusters
  • Tests tagged with UpgradeStatus will need better scrutiny before merge because they will run in Default jobs and not just TP jobs
  • The actual promotion in o/oc is still gated by data evidence of passing tests, in spirit with the usual promotion process

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 openshift-eng/jira-lifecycle-plugin repository.

@openshift-ci openshift-ci bot added the size/S Denotes a PR that changes 10-29 lines, ignoring generated files. label Jul 23, 2025
@openshift-ci openshift-ci bot requested review from everettraven and JoelSpeed July 23, 2025 17:56
@petr-muller
Copy link
Member Author

petr-muller commented Jul 23, 2025

/hold

Hold for the OTA-1578 / openshift/cluster-version-operator#1216 dependency

@openshift-ci openshift-ci bot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jul 23, 2025
@openshift-ci-robot
Copy link

openshift-ci-robot commented Jul 23, 2025

@petr-muller: This pull request references OTA-1580 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.20.0" version, but no target version was set.

In response to this:

This is a request for an exception in the feature promotion process.

Proposed promotion process:

  1. Promote UpgradeStatus gate here. This does not actually put any functional change into customers' hands.
  2. Promotion will allow tests tagged with UpgradeStatus to run in Default update jobs (because there are not and cannot be any TP update jobs)
  3. Update-time tests will execute and feed results into Sippy feature view
  4. The feature view will need to be monitored manually to meet the criteria otherwise enforced by verify-feature-promotion
  5. Once that happens, actually promote the feature through OTA-1581: Promote oc adm upgrade status to general availability oc#2063

Why is exception needed:

The feature promoted under UpgradeStatus gate identifier is actually entirely client-side implementation of the oc adm upgrade status command. Promoting the feature in o/api has no effect on any functionality in the cluster; nothing reads and depends on this identifier in the cluster (as of Jul 23, with the exception of the about to be removed behavior, tracked in OTA-1578 / openshift/cluster-version-operator#1216 expected to merge soon). The actual "promotion" of the feature would be done in the o/oc repository with a PR such as openshift/oc#2063 (intentionally /hold for now because of its "feature promotion" semantics).

We wanted to utilize the UpgradeStatus gate to pursue the data-driven promotion process, but the process does not seem to accommodate features tied to OCP updates. Features are expected to accumulate test coverage in TechPreview (TP) jobs, but there are no TP jobs that exercise a cluster update. Minor version update TP cannot exist by definition (TechPreviewNoUpgrade). Patch version update jobs can exist in theory, but is likely that OCP cannot realistically maintain such jobs because teams are allowed to make update-breaking changes in TP (such as promotion where a v1alpha1 API will be replaced with a v1 one) until the version is GA. That means update-related features cannot easily accumulate sufficient test data in available TechPreview jobs (we may need to address this gap in the future because the exception process proposed here will not succeed for cluster-side behavior).

For this feature specifically, running in TechPreview jobs would actually increase risk of problems after promotion. The conditional behavior is entirely client-side; testing it against TP clusters carries a risk of inadvertedly depending on some cluster-side TP-only feature. Such feature could be missing in Default clusters and the client-side behavior can break when run against a Default cluster. For CLI-side features, it seems more appropriate to test TP behavior against a Default cluster instead. This is possible, but non-TP jobs will not execute tests tagged with a TP feature gate name such as FeatureGate.

How are regressions prevented:

  • Promoting UpgradeStatus in o/api has no risks because it does not change any behavior except test selection
  • Running candidate CLI behavior against Default clusters actually provides better quality signal than against TP clusters
  • Tests tagged with UpgradeStatus will need better scrutiny before merge because they will run in Default jobs and not just TP jobs
  • The actual promotion in o/oc is still gated by data evidence of passing tests, in spirit with the usual promotion process

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 openshift-eng/jira-lifecycle-plugin repository.

Copy link
Member

@wking wking left a comment

Choose a reason for hiding this comment

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

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Jul 23, 2025
@openshift-ci-robot
Copy link

openshift-ci-robot commented Jul 23, 2025

@petr-muller: This pull request references OTA-1580 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.20.0" version, but no target version was set.

In response to this:

This is a request for an exception in the feature promotion process.

Proposed promotion process:

  1. Promote UpgradeStatus gate here. This does not actually put any functional change into customers' hands.
  2. Promotion will allow tests tagged with UpgradeStatus to run in Default update jobs (because there are not and cannot be any TP update jobs)
  3. Update-time tests will execute and feed results into Sippy feature view
  4. The feature view will need to be monitored manually to meet the criteria otherwise enforced by verify-feature-promotion
  5. Once that happens, actually promote the feature through OTA-1581: Promote oc adm upgrade status to general availability oc#2063

Why is exception needed:

The feature promoted under UpgradeStatus gate identifier is actually entirely client-side implementation of the oc adm upgrade status command. Promoting the feature in o/api has no effect on any functionality in the cluster; nothing reads and depends on this identifier in the cluster (as of Jul 23, with the exception of the about to be removed behavior, tracked in OTA-1578 / openshift/cluster-version-operator#1216 expected to merge soon). The actual "promotion" of the feature would be done in the o/oc repository with a PR such as openshift/oc#2063 (intentionally /hold for now because of its "feature promotion" semantics).

We wanted to utilize the UpgradeStatus gate to pursue the data-driven promotion process, but the process does not seem to accommodate features tied to OCP updates. Features are expected to accumulate test coverage in TechPreview (TP) jobs, but there are no TP jobs that exercise a cluster update. Minor version update TP cannot exist by definition (TechPreviewNoUpgrade). Patch version update jobs can exist in theory, but is likely that OCP cannot realistically maintain such jobs because teams are allowed to make update-breaking changes in TP (such as promotion where a v1alpha1 API will be replaced with a v1 one) until the version is GA. That means update-related features cannot easily accumulate sufficient test data in available TechPreview jobs (we may need to address this gap in the future because the exception process proposed here will not succeed for cluster-side behavior).

For this feature specifically, running in TechPreview jobs would actually increase risk of problems after promotion. The conditional behavior is entirely client-side; testing it against TP clusters carries a risk of inadvertedly depending on some cluster-side TP-only feature. Such feature could be missing in Default clusters and the client-side behavior can break when run against a Default cluster. For CLI-side features, it seems more appropriate to test TP behavior against a Default cluster instead. This is possible, but non-TP jobs will not execute tests tagged with a TP feature gate name such as UpgradeStatus.

How are regressions prevented:

  • Promoting UpgradeStatus in o/api has no risks because it does not change any behavior except test selection
  • Running candidate CLI behavior against Default clusters actually provides better quality signal than against TP clusters
  • Tests tagged with UpgradeStatus will need better scrutiny before merge because they will run in Default jobs and not just TP jobs
  • The actual promotion in o/oc is still gated by data evidence of passing tests, in spirit with the usual promotion process

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 openshift-eng/jira-lifecycle-plugin repository.

@petr-muller
Copy link
Member Author

/hold cancel

openshift/cluster-version-operator#1216 merged

@openshift-ci openshift-ci bot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jul 24, 2025
@petr-muller
Copy link
Member Author

We agreed to gate this PR on a started SBAR process.

/hold

@openshift-ci openshift-ci bot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jul 24, 2025
@petr-muller
Copy link
Member Author

/test verify-feature-promotion

@petr-muller
Copy link
Member Author

/test ci/prow/verify-feature-promotion

Copy link
Contributor

openshift-ci bot commented Aug 12, 2025

@petr-muller: The specified target(s) for /test were not found.
The following commands are available to trigger required jobs:

/test build
/test e2e-aws-ovn
/test e2e-aws-ovn-hypershift
/test e2e-aws-ovn-hypershift-conformance
/test e2e-aws-ovn-techpreview
/test e2e-aws-serial-1of2
/test e2e-aws-serial-2of2
/test e2e-aws-serial-techpreview-1of2
/test e2e-aws-serial-techpreview-2of2
/test e2e-upgrade
/test e2e-upgrade-out-of-change
/test images
/test integration
/test lint
/test minor-e2e-upgrade-minor
/test minor-images
/test okd-scos-images
/test unit
/test verify
/test verify-client-go
/test verify-crd-schema
/test verify-deps
/test verify-feature-promotion

The following commands are available to trigger optional jobs:

/test e2e-azure
/test e2e-gcp
/test okd-scos-e2e-aws-ovn

Use /test all to run all jobs.

In response to this:

/test ci/prow/verify-feature-promotion

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-sigs/prow repository.

@petr-muller
Copy link
Member Author

/test verify-feature-promotion

7 similar comments
@petr-muller
Copy link
Member Author

/test verify-feature-promotion

@petr-muller
Copy link
Member Author

/test verify-feature-promotion

@petr-muller
Copy link
Member Author

/test verify-feature-promotion

@petr-muller
Copy link
Member Author

/test verify-feature-promotion

@petr-muller
Copy link
Member Author

/test verify-feature-promotion

@petr-muller
Copy link
Member Author

/test verify-feature-promotion

@petr-muller
Copy link
Member Author

/test verify-feature-promotion

@petr-muller petr-muller force-pushed the ota-1580-promote-upgrade-status branch from be85fbe to 3fa6e41 Compare August 18, 2025 16:49
@petr-muller petr-muller changed the title OTA-1580: "Promote" UpgradeStatus to Default (tests only) OTA-1580: Promote UpgradeStatus to Default Aug 18, 2025
@petr-muller
Copy link
Member Author

/hold cancel

@openshift-ci openshift-ci bot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Aug 18, 2025
@hongkailiu
Copy link
Member

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Aug 18, 2025
@petr-muller
Copy link
Member Author

/retest-required

@JoelSpeed
Copy link
Contributor

/lgtm

@openshift-merge-robot openshift-merge-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Aug 19, 2025
@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Aug 19, 2025
OTA uses `UpgradeStatus` feature gate name to identify the CLI-side functionality described in OTA-1577 (`oc adm upgrade status` command).

The `UpgradeStatus` feature gate does not enable any cluster-side functionality (neither API changes or any controller code). The actual functionality will be enabled in `oc` through openshift/oc#2063. The `UpgradeStatus` feature gate thus serves only as a vehicle to perform the data-driven promotion decision by tying the appropriate test coverage to this name so that the promotion criteria can be automatically checked.

Therefore, this PR serves as a formal decision record only, and after it merges, it means openshift/oc#2063 is allowed to merge.
@petr-muller petr-muller force-pushed the ota-1580-promote-upgrade-status branch from 3fa6e41 to 3443c48 Compare August 19, 2025 09:15
@openshift-ci openshift-ci bot removed the lgtm Indicates that a PR is ready to be merged. label Aug 19, 2025
@openshift-merge-robot openshift-merge-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Aug 19, 2025
@JoelSpeed
Copy link
Contributor

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Aug 19, 2025
Copy link
Contributor

openshift-ci bot commented Aug 19, 2025

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: hongkailiu, JoelSpeed, petr-muller, wking

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

The pull request process is described here

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-robot
Copy link

/retest-required

Remaining retests: 0 against base HEAD 2d02a45 and 2 for PR HEAD 3443c48 in total

@petr-muller
Copy link
Member Author

/hold

oc adm upgrade status does not work on hypershift (this limitation was accepted when promotion intent decision was made), cannot pass ci/prow/e2e-aws-ovn-hypershift-conformance until openshift/origin#30132

@openshift-ci openshift-ci bot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Aug 19, 2025
@petr-muller
Copy link
Member Author

/hold cancel
/retest-required

@openshift-ci openshift-ci bot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Aug 19, 2025
@openshift-ci-robot
Copy link

/retest-required

Remaining retests: 0 against base HEAD 4bbb180 and 2 for PR HEAD 3443c48 in total

1 similar comment
@openshift-ci-robot
Copy link

/retest-required

Remaining retests: 0 against base HEAD 4bbb180 and 2 for PR HEAD 3443c48 in total

Copy link
Contributor

openshift-ci bot commented Aug 20, 2025

@petr-muller: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name Commit Details Required Rerun command
ci/prow/okd-scos-e2e-aws-ovn 3443c48 link false /test okd-scos-e2e-aws-ovn

Full PR test history. Your PR dashboard.

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-sigs/prow repository. I understand the commands that are listed here.

@openshift-merge-bot openshift-merge-bot bot merged commit 6282350 into openshift:master Aug 20, 2025
26 of 27 checks passed
@petr-muller petr-muller deleted the ota-1580-promote-upgrade-status branch August 20, 2025 14:56
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. jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. lgtm Indicates that a PR is ready to be merged. size/S Denotes a PR that changes 10-29 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants