Skip to content

CORS-4387: Promote AWS DualStack to Default#2797

Open
sadasu wants to merge 2 commits into
openshift:masterfrom
sadasu:aws-dualstack-promotion
Open

CORS-4387: Promote AWS DualStack to Default#2797
sadasu wants to merge 2 commits into
openshift:masterfrom
sadasu:aws-dualstack-promotion

Conversation

@sadasu

@sadasu sadasu commented Apr 7, 2026

Copy link
Copy Markdown
Contributor

Also make it available in OKD.

@openshift-ci-robot

Copy link
Copy Markdown

Pipeline controller notification
This repo is configured to use the pipeline controller. Second-stage tests will be triggered either automatically or after lgtm label is added, depending on the repository configuration. The pipeline controller will automatically detect which contexts are required and will utilize /test Prow commands to trigger the second stage.

For optional jobs, comment /test ? to see a list of all defined jobs. To trigger manually all jobs from second stage use /pipeline required command.

This repository is configured in: LGTM mode

@openshift-ci

openshift-ci Bot commented Apr 7, 2026

Copy link
Copy Markdown
Contributor

Hello @sadasu! 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.

@coderabbitai

coderabbitai Bot commented Apr 7, 2026

Copy link
Copy Markdown

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

  • @coderabbitai resume to resume automatic reviews.
  • @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

  • ▶️ Resume reviews
  • 🔍 Trigger review
📝 Walkthrough

Walkthrough

This pull request promotes the AWSDualStackInstall feature gate from tech-preview and dev-preview modes to Default and OKD deployment types. The changes add an ipFamily field to Infrastructure and ControllerConfig CRDs with enum values for IPv4, DualStackIPv6Primary, and DualStackIPv4Primary, enforcing immutability after initial set via x-kubernetes-validations rules. The feature gate enable conditions in features/features.go are expanded to include inDefault() and inOKD() alongside existing preview conditions. FeatureGate manifests across Hypershift and SelfManagedHA configurations move AWSDualStackInstall from disabled to enabled lists. Test YAML files are updated to include expected ipFamily: IPv4 values in platform status outputs and add cloudLoadBalancerConfig.dnsType: PlatformDefault expectations across multiple test scenarios. The features.md documentation is updated to reflect the expanded feature gate availability.

Possibly related PRs

  • openshift/api#2775: Updates Infrastructure and ControllerConfig test expectations for AWS platform status including cloudLoadBalancerConfig.dnsType and ipFamily field handling in related dual-stack test scenarios.

Suggested reviewers

  • sinnykumari
  • everettraven
🚥 Pre-merge checks | ✅ 14 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Microshift Test Compatibility ⚠️ Warning Ginkgo tests are being added that validate config.openshift.io (Infrastructure) and machineconfiguration.openshift.io (ControllerConfig) APIs, which are unavailable on MicroShift. Test names use [G... Add [apigroup:config.openshift.io] and [apigroup:machineconfiguration.openshift.io] tags to test names, or add [Skipped:MicroShift] labels. Alternatively, wrap tests in exutil.IsMicroShiftCluster() checks with g.Skip().
✅ Passed checks (14 passed)
Check name Status Explanation
Title check ✅ Passed The title 'CORS-4387: Promote AWS DualStack to Default' clearly and concisely summarizes the main objective of the PR—promoting the AWS DualStack feature to default status, which is confirmed by the extensive changes to feature gate configurations, CRD schemas, and test files throughout the changeset.
Description check ✅ Passed The description 'Also make it available in OKD' is concise but directly related to the changeset; it complements the title by noting the secondary objective of extending AWS DualStack support to OKD, which is reflected in changes to OKD-specific CRD files and feature gate configurations.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
Stable And Deterministic Test Names ✅ Passed All Ginkgo test names in the PR are stable and deterministic. Test names are derived from static YAML fields (testEntry.Name) and CRD metadata (featureSets, clusterProfiles, annotations). No dynami...
Test Structure And Quality ✅ Passed PR does not modify Ginkgo test code (*_test.go files); it only changes test fixtures (.yaml), CRD schemas, feature gates, docs, and non-test Go code. The custom check is inapplicable to this PR.
Single Node Openshift (Sno) Test Compatibility ✅ Passed This PR does not add any new Ginkgo e2e tests. All changes are to YAML CRD test data files, feature gate configurations, CRD definitions, and documentation—not Go test code.
Topology-Aware Scheduling Compatibility ✅ Passed PR modifies only CRD schemas, test configurations, and feature gate definitions. No deployment manifests, operator code, or scheduling constraints (affinity, topology spread, nodeSelector) are intr...
Ote Binary Stdout Contract ✅ Passed PR modifies features/features.go (library), okd_featureset_parity_test.go (unit test), and tests/suite_test.go (Ginkgo suite). No stdout violations detected: suite_test.go correctly uses GinkgoWrit...
Ipv6 And Disconnected Network Test Compatibility ✅ Passed PR adds no new Ginkgo e2e tests. Changes are limited to CRD schemas, test configuration files, feature gate manifests, and source code definitions for feature gates.
No-Weak-Crypto ✅ Passed PR contains no cryptographic operations, weak algorithms, custom crypto, or non-constant-time secret comparisons. Changes are feature gate promotion, CRD schema, test configs, and documentation only.
Container-Privileges ✅ Passed No container privilege escalation settings found. PR changes are configuration schemas, test fixtures, feature gates, and documentation—not container/pod manifests with security contexts.
No-Sensitive-Data-In-Logs ✅ Passed No logging statements found in the PR. The changes consist entirely of YAML test configs, CRD manifests, feature gate manifests, feature gate code metadata, and documentation—none introduce logging...

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Comment @coderabbitai help to get the list of available commands.

@openshift-ci openshift-ci Bot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Apr 7, 2026
@openshift-ci

openshift-ci Bot commented Apr 7, 2026

Copy link
Copy Markdown
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign joelspeed for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found 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

@qodo-code-review

Copy link
Copy Markdown

Review Summary by Qodo

Promote AWS DualStack to Default and enable in OKD

✨ Enhancement

Grey Divider

Walkthroughs

Description
• Promote AWSDualStackInstall feature gate to default in OCP and OKD
• Enable feature in both Default and OKD product scopes
• Add ipFamily field to AWS platform status with validation
• Remove cloudLoadBalancerConfig from test expectations
• Fix indentation in FeatureGateConfidentialCluster definition
Diagram
flowchart LR
  A["AWSDualStackInstall Feature Gate"] -->|"Enable in Default"| B["Default Product Scope"]
  A -->|"Enable in OKD"| C["OKD Product Scope"]
  B -->|"Add ipFamily field"| D["AWS Platform Status"]
  C -->|"Add ipFamily field"| D
  D -->|"Validation Rules"| E["Immutable, IPv4/DualStack options"]
Loading

Grey Divider

File Changes

1. features/features.go ✨ Enhancement +8/-8

Enable AWSDualStackInstall in Default and OKD

features/features.go


2. config/v1/tests/infrastructures.config.openshift.io/AAA_ungated.yaml 🧪 Tests +2/-0

Add ipFamily field to AWS platform status

config/v1/tests/infrastructures.config.openshift.io/AAA_ungated.yaml


3. config/v1/tests/infrastructures.config.openshift.io/AWSDualStackInstall.yaml 🧪 Tests +1/-8

Update test cases for dual-stack configuration

config/v1/tests/infrastructures.config.openshift.io/AWSDualStackInstall.yaml


View more (15)
4. config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_infrastructures-Default.crd.yaml ⚙️ Configuration changes +15/-0

Add ipFamily property to AWS infrastructure CRD

config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_infrastructures-Default.crd.yaml


5. config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_infrastructures-OKD.crd.yaml ⚙️ Configuration changes +15/-0

Add ipFamily property to AWS infrastructure CRD

config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_infrastructures-OKD.crd.yaml


6. features.md 📝 Documentation +1/-1

Update feature gate status documentation

features.md


7. machineconfiguration/v1/tests/controllerconfigs.machineconfiguration.openshift.io/AWSDualStackInstall.yaml 🧪 Tests +1/-4

Update controller config test cases

machineconfiguration/v1/tests/controllerconfigs.machineconfiguration.openshift.io/AWSDualStackInstall.yaml


8. machineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_controllerconfigs-Default.crd.yaml ⚙️ Configuration changes +15/-0

Add ipFamily property to controller config CRD

machineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_controllerconfigs-Default.crd.yaml


9. machineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_controllerconfigs-OKD.crd.yaml ⚙️ Configuration changes +15/-0

Add ipFamily property to controller config CRD

machineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_controllerconfigs-OKD.crd.yaml


10. openapi/openapi.json ✨ Enhancement +245/-1

Add PacemakerCluster v1 API definitions

openapi/openapi.json


11. payload-manifests/crds/0000_10_config-operator_01_infrastructures-Default.crd.yaml ⚙️ Configuration changes +15/-0

Add ipFamily property to infrastructure CRD

payload-manifests/crds/0000_10_config-operator_01_infrastructures-Default.crd.yaml


12. payload-manifests/crds/0000_10_config-operator_01_infrastructures-OKD.crd.yaml ⚙️ Configuration changes +15/-0

Add ipFamily property to infrastructure CRD

payload-manifests/crds/0000_10_config-operator_01_infrastructures-OKD.crd.yaml


13. payload-manifests/crds/0000_80_machine-config_01_controllerconfigs-Default.crd.yaml ⚙️ Configuration changes +15/-0

Add ipFamily property to controller config CRD

payload-manifests/crds/0000_80_machine-config_01_controllerconfigs-Default.crd.yaml


14. payload-manifests/crds/0000_80_machine-config_01_controllerconfigs-OKD.crd.yaml ⚙️ Configuration changes +15/-0

Add ipFamily property to controller config CRD

payload-manifests/crds/0000_80_machine-config_01_controllerconfigs-OKD.crd.yaml


15. payload-manifests/featuregates/featureGate-4-10-Hypershift-Default.yaml ⚙️ Configuration changes +3/-3

Move AWSDualStackInstall to enabled features

payload-manifests/featuregates/featureGate-4-10-Hypershift-Default.yaml


16. payload-manifests/featuregates/featureGate-4-10-Hypershift-OKD.yaml ⚙️ Configuration changes +3/-3

Move AWSDualStackInstall to enabled features

payload-manifests/featuregates/featureGate-4-10-Hypershift-OKD.yaml


17. payload-manifests/featuregates/featureGate-4-10-SelfManagedHA-Default.yaml ⚙️ Configuration changes +3/-3

Move AWSDualStackInstall to enabled features

payload-manifests/featuregates/featureGate-4-10-SelfManagedHA-Default.yaml


18. payload-manifests/featuregates/featureGate-4-10-SelfManagedHA-OKD.yaml ⚙️ Configuration changes +3/-3

Move AWSDualStackInstall to enabled features

payload-manifests/featuregates/featureGate-4-10-SelfManagedHA-OKD.yaml


Grey Divider

Qodo Logo

@qodo-code-review

qodo-code-review Bot commented Apr 7, 2026

Copy link
Copy Markdown

Code Review by Qodo

🐞 Bugs (1)   📘 Rule violations (1)   📎 Requirement gaps (0)   🎨 UX Issues (0)
🐞\ ≡ Correctness (1)
📘\ ⚙ Maintainability (1)

Grey Divider


Action required

1. ipFamily docs omit constraints 📘
Description
The new ipFamily schema includes a default, an enum, and an immutability
x-kubernetes-validations rule, but its description does not document the default/allowed values
or the immutability constraint. This violates the requirement that validation marker semantics be
documented in field comments/user-facing docs.
Code

config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_infrastructures-Default.crd.yaml[R1188-1202]

+                      ipFamily:
+                        default: IPv4
+                        description: |-
+                          ipFamily specifies the IP protocol family that should be used for AWS
+                          network resources. This controls whether AWS resources are created with
+                          IPv4-only, or dual-stack networking with IPv4 or IPv6 as the primary
+                          protocol family.
+                        enum:
+                        - IPv4
+                        - DualStackIPv6Primary
+                        - DualStackIPv4Primary
+                        type: string
+                        x-kubernetes-validations:
+                        - message: ipFamily is immutable once set
+                          rule: oldSelf == '' || self == oldSelf
Evidence
PR Compliance ID 5 requires that fields with kubebuilder validation markers have comments
documenting the markers’ semantics (default behavior, enum values, and validation rules). The added
ipFamily schema shows default, enum, and an immutability validation rule, but the
description text does not state the default value behavior, enumerate the valid values, or mention
immutability.

AGENTS.md
config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_infrastructures-Default.crd.yaml[1188-1202]
machineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_controllerconfigs-Default.crd.yaml[1480-1494]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The `ipFamily` field’s schema adds `default`, `enum`, and an immutability `XValidation`, but the user-facing field documentation does not describe:
- what happens when the field is omitted (defaulting)
- the allowed enum values (and what each means)
- that the value is immutable once set

## Issue Context
This is surfaced in generated CRD/OpenAPI documentation, so missing details violate the requirement that validation marker semantics be documented.

## Fix Focus Areas
- config/v1/types_infrastructure.go[567-577]
- config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_infrastructures-Default.crd.yaml[1188-1202]
- config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_infrastructures-OKD.crd.yaml[1188-1202]
- machineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_controllerconfigs-Default.crd.yaml[1480-1494]
- machineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_controllerconfigs-OKD.crd.yaml[1480-1494]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Remediation recommended

2. ipFamily default locks value 🐞
Description
The Infrastructure AWS status field ipFamily is defaulted to IPv4 and validated as immutable, so any
create/update that omits ipFamily will persist IPv4 and subsequently reject attempts to set
DualStack* values. This creates a write-once/ordering trap: once the default is applied, the API
prevents later correction to a DualStack value.
Code

config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_infrastructures-Default.crd.yaml[R1188-1202]

+                      ipFamily:
+                        default: IPv4
+                        description: |-
+                          ipFamily specifies the IP protocol family that should be used for AWS
+                          network resources. This controls whether AWS resources are created with
+                          IPv4-only, or dual-stack networking with IPv4 or IPv6 as the primary
+                          protocol family.
+                        enum:
+                        - IPv4
+                        - DualStackIPv6Primary
+                        - DualStackIPv4Primary
+                        type: string
+                        x-kubernetes-validations:
+                        - message: ipFamily is immutable once set
+                          rule: oldSelf == '' || self == oldSelf
Evidence
The Default Infrastructure CRD adds ipFamily with a server-side default of IPv4 and an immutability
validation rule, so once ipFamily becomes IPv4 (including via defaulting) it cannot be changed. The
AWSDualStackInstall test suite explicitly demonstrates that omitting ipFamily results in it being
defaulted to IPv4 in stored status, confirming that an omission will persist the default and
therefore lock out later DualStack updates.

config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_infrastructures-Default.crd.yaml[1184-1202]
config/v1/tests/infrastructures.config.openshift.io/AWSDualStackInstall.yaml[18-66]
config/v1/types_infrastructure.go[567-577]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`status.platformStatus.aws.ipFamily` is both **defaulted** to `IPv4` and marked **immutable once set**. This combination makes the default “sticky”: any object created/updated without explicitly setting `ipFamily` will have `IPv4` persisted, and subsequent updates to a `DualStack*` value will be rejected.

## Issue Context
This field is intended to control AWS networking family selection. With a persisted default and immutability, the system effectively requires that any DualStack install set `ipFamily` correctly on the *very first* write that causes defaulting; otherwise it becomes permanently locked to IPv4.

## How to fix
Choose one of the following (in priority order):
1. **Remove the API default** for `ipFamily` (keep it logically defaulting to IPv4 in consuming components) so omitting the field does not persist a value that later blocks explicit DualStack selection.
2. Or **adjust the immutability rule** to permit transitioning from an implicitly defaulted IPv4 to an explicit DualStack value during an initial configuration window (if such a window exists in your API semantics).

After changing the source markers, regenerate CRD/openapi artifacts.

## Fix Focus Areas
- config/v1/types_infrastructure.go[567-577]
- config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_infrastructures-Default.crd.yaml[1184-1202]
- payload-manifests/crds/0000_10_config-operator_01_infrastructures-Default.crd.yaml[1184-1202]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

ⓘ The new review experience is currently in Beta. Learn more

Grey Divider

Qodo Logo

Comment on lines +1188 to +1202
ipFamily:
default: IPv4
description: |-
ipFamily specifies the IP protocol family that should be used for AWS
network resources. This controls whether AWS resources are created with
IPv4-only, or dual-stack networking with IPv4 or IPv6 as the primary
protocol family.
enum:
- IPv4
- DualStackIPv6Primary
- DualStackIPv4Primary
type: string
x-kubernetes-validations:
- message: ipFamily is immutable once set
rule: oldSelf == '' || self == oldSelf

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Action required

1. ipfamily docs omit constraints 📘 Rule violation ⚙ Maintainability

The new ipFamily schema includes a default, an enum, and an immutability
x-kubernetes-validations rule, but its description does not document the default/allowed values
or the immutability constraint. This violates the requirement that validation marker semantics be
documented in field comments/user-facing docs.
Agent Prompt
## Issue description
The `ipFamily` field’s schema adds `default`, `enum`, and an immutability `XValidation`, but the user-facing field documentation does not describe:
- what happens when the field is omitted (defaulting)
- the allowed enum values (and what each means)
- that the value is immutable once set

## Issue Context
This is surfaced in generated CRD/OpenAPI documentation, so missing details violate the requirement that validation marker semantics be documented.

## Fix Focus Areas
- config/v1/types_infrastructure.go[567-577]
- config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_infrastructures-Default.crd.yaml[1188-1202]
- config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_infrastructures-OKD.crd.yaml[1188-1202]
- machineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_controllerconfigs-Default.crd.yaml[1480-1494]
- machineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_controllerconfigs-OKD.crd.yaml[1480-1494]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

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.

This sounds like a legitimate issue to me

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.

Right. I think this is just saying the comment should contain something like:

// Valid values are "IPv4", "DualStackIPv4Primary", and "DualStackIPv6Primary". When omitted, the default value is "IPv4".

It's also outside the scope of this PR, so I would consider it more of a nice to have

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

@nrb, @patrickdillon I can add a follow-up patch for all 3 platforms. I don't think we had followed that pattern in the past. But a good recommendation to follow for the future.

@sadasu sadasu changed the title Promote AWS DualStack to Default CORS-4387: Promote AWS DualStack to Default Apr 7, 2026
@openshift-ci-robot openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Apr 7, 2026
@openshift-ci-robot

openshift-ci-robot commented Apr 7, 2026

Copy link
Copy Markdown

@sadasu: This pull request references CORS-4387 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 story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Also make it available in OKD.

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.

@sadasu

sadasu commented Apr 7, 2026

Copy link
Copy Markdown
Contributor Author

/jira refresh

@openshift-ci-robot

openshift-ci-robot commented Apr 7, 2026

Copy link
Copy Markdown

@sadasu: This pull request references CORS-4387 which is a valid jira issue.

Details

In response to this:

/jira refresh

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.

@everettraven

Copy link
Copy Markdown
Contributor

Checking the promotion verification results, it looks like:

  • There is no HyperShift testing - is this feature supported on HyperShift?
  • There are two tests that aren't meeting the pass/run criteria:
    • install should succeed: overall - looks like there is a known component readiness regression causing problems in TPNU only here that is probably dropping that just below the 95% threshold. Seems reasonable to override to me.
    • install should succeed: post check - looks like only 4 runs, is this test related to this feature?

I also noticed openshift/release#76769 - this seems like testing that we would want to make sure is in place and has captured sufficient runs prior to promoting?

@patrickdillon

Copy link
Copy Markdown
Contributor
* There is no HyperShift testing - is this feature supported on HyperShift?

It's not in the plan to support this in hypershift, so no. But it's a good question: hypershift should be able to take advantage of this work. On the other hand I'm sure further work is required to enable it, so we will move forward with no hypershift support.

I also noticed openshift/release#76769 - this seems like testing that we would want to make sure is in place and has captured sufficient runs prior to promoting?

Exactly. This is the only testing that is actually exercising the AWS Dual Stack functionality, so the other test failures/results are mostly noise... We have been running these tests in various forms, analyzing the test failures and fix tech debt in the e2e tests for a while now. openshift/release#76769 should merge today and we can accumulate some results quickly with gangway. Overall the feature is stable, and well tested.

@sadasu

sadasu commented Apr 9, 2026

Copy link
Copy Markdown
Contributor Author

/test verify-feature-promotion

@qodo-code-review

qodo-code-review Bot commented Apr 9, 2026

Copy link
Copy Markdown

PR-Agent: could not fine a component named verify-feature-promotion in a supported language in this PR.

@sadasu

sadasu commented Apr 9, 2026

Copy link
Copy Markdown
Contributor Author

/test verify-feature-promotion

@qodo-code-review

qodo-code-review Bot commented Apr 9, 2026

Copy link
Copy Markdown

PR-Agent: could not fine a component named verify-feature-promotion in a supported language in this PR.

@patrickdillon

Copy link
Copy Markdown
Contributor

/test verify-feature-promotion

@qodo-code-review

qodo-code-review Bot commented Apr 10, 2026

Copy link
Copy Markdown

PR-Agent: could not fine a component named verify-feature-promotion in a supported language in this PR.

@sadasu

sadasu commented Apr 10, 2026

Copy link
Copy Markdown
Contributor Author

/test verify-feature-promotion

@qodo-code-review

qodo-code-review Bot commented Apr 10, 2026

Copy link
Copy Markdown

PR-Agent: could not fine a component named verify-feature-promotion in a supported language in this PR.

@sadasu

sadasu commented Apr 10, 2026

Copy link
Copy Markdown
Contributor Author

/test verify-feature-promotion

@qodo-code-review

qodo-code-review Bot commented Apr 10, 2026

Copy link
Copy Markdown

PR-Agent: could not fine a component named verify-feature-promotion in a supported language in this PR.

@sadasu

sadasu commented Apr 21, 2026

Copy link
Copy Markdown
Contributor Author

/hold

Promotion has been moved to 5.0

@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 Apr 21, 2026
@sadasu

sadasu commented Apr 27, 2026

Copy link
Copy Markdown
Contributor Author

/test verify-feature-promotion

@sadasu

sadasu commented Jun 23, 2026

Copy link
Copy Markdown
Contributor Author

/test verify-feature-promotion

1 similar comment
@sadasu

sadasu commented Jun 24, 2026

Copy link
Copy Markdown
Contributor Author

/test verify-feature-promotion

@sadasu

sadasu commented Jun 24, 2026

Copy link
Copy Markdown
Contributor Author

@everettraven, @JoelSpeed We are finally ready to promote this feature. Looking at the results for verify-feature-promotion, it appears that we satisfy all conditions except for HyperShift.

As mentioned in #2797 (comment), HyperShift support is out of scope for this work at this time. [Working with PMs to figure out HyperShift support.]

To indicate that, I did not include inClusterProfile(Hypershift) in our enable() list. I guess that is not being considered in the verify-feature-promotion test?

@sadasu

sadasu commented Jun 24, 2026

Copy link
Copy Markdown
Contributor Author

Hi @JoelSpeed and @everettraven ! I also see that Sippy's view of the feature gate is AWSDualstackInstall

Is there any way to not include HyperShift in this list? Thanks!

@sadasu

sadasu commented Jun 24, 2026

Copy link
Copy Markdown
Contributor 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 Jun 24, 2026
@JoelSpeed

JoelSpeed commented Jun 25, 2026

Copy link
Copy Markdown
Contributor

@sadasu the current enable() call you have enables in all cluster profiles because you aren't otherwise restricting it. So this is currently enabling the feature in HyperShift. Has the feature been worked in HyperShift at all?

Looking at what actually matters here, it would be good to look specifically at AWS dual stack cluster E2Es, can you link sippy for these jobs? Would that be:

Looks like there were some failures there in the last few days, could you take a look at those and see if they could be related to this feature

@sadasu
sadasu force-pushed the aws-dualstack-promotion branch 2 times, most recently from 1a5ecce to 2812e68 Compare June 29, 2026 17:05
@sadasu

sadasu commented Jul 13, 2026

Copy link
Copy Markdown
Contributor Author

/test verify-feature-promotion

@JoelSpeed

Copy link
Copy Markdown
Contributor

I'm not convinced the new feature promotion logic is quite working (cc @everettraven), but looking directly at the jobs, they also look fairly sad in the last week so lets look into that

@JoelSpeed

Copy link
Copy Markdown
Contributor

#2928 Will fix the broken featuregate analysis

@sadasu

sadasu commented Jul 14, 2026

Copy link
Copy Markdown
Contributor Author

I'm not convinced the new feature promotion logic is quite working (cc @everettraven), but looking directly at the jobs, they also look fairly sad in the last week so lets look into that

Yeah, there is a recent degradation. I am looking into those failures.

@sadasu

sadasu commented Jul 14, 2026

Copy link
Copy Markdown
Contributor Author

/test verify-feature-promotion

2 similar comments
@tthvo

tthvo commented Jul 15, 2026

Copy link
Copy Markdown
Member

/test verify-feature-promotion

@sadasu

sadasu commented Jul 16, 2026

Copy link
Copy Markdown
Contributor Author

/test verify-feature-promotion

@sadasu

sadasu commented Jul 16, 2026

Copy link
Copy Markdown
Contributor Author

Looking at https://sippy-auth.dptools.openshift.org/sippy-ng/feature_gates/5.0/AWSDualStackInstall we are in good shape but if we look for runs having 95% pass rate with 6K conformance tests on DualStack clusters, we are likely to get there only after all other TP features have hardened.

@sadasu

sadasu commented Jul 16, 2026

Copy link
Copy Markdown
Contributor Author

#2937 updates verify-feature-promotion output to indicate pass percentage for install should succeed tests for featuregates that include "Install" in their name. Goal is that manual verification of the health of the job/feature is warranted only after "install should succeed" results are good but overall pass % isn't at 95%. Hope this helps the API team!

@sadasu

sadasu commented Jul 16, 2026

Copy link
Copy Markdown
Contributor Author

/test verify-feature-promotion

Also make it available in OKD.
@sadasu
sadasu force-pushed the aws-dualstack-promotion branch from 2812e68 to 748a7af Compare July 16, 2026 23:51
@openshift-ci openshift-ci Bot added size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. and removed size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Jul 16, 2026
@sadasu
sadasu force-pushed the aws-dualstack-promotion branch from 748a7af to 3b667b9 Compare July 17, 2026 00:29
@openshift-ci openshift-ci Bot added size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. and removed size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. labels Jul 17, 2026
Augment `verify-feature-promotion` output to indicate pass percentage
for `install should succeed` tests for featuregates that include
"Install" in their name.

This update gives a better indication of whether Install features
are failing at installation or later during execution of e2e
conformance tests.

This update does not change the criteria for reporting success
but adds more information in the output for easier analysis of
feature state.
@openshift-ci

openshift-ci Bot commented Jul 17, 2026

Copy link
Copy Markdown
Contributor

@sadasu: The following tests 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/verify-hypershift-integration fcb2ab3 link true /test verify-hypershift-integration
ci/prow/verify fcb2ab3 link true /test verify
ci/prow/verify-deps fcb2ab3 link true /test verify-deps
ci/prow/verify-feature-promotion fcb2ab3 link true /test verify-feature-promotion

Full PR test history. Your PR dashboard.

Details

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants