Repository navigation
Conversation
VSphereMultiVCenters is already enabled in Default/DevPreviewNoUpgrade/ TechPreviewNoUpgrade on this release, so the FeatureGateAwareMaxItems split (1 vs 3) was functionally always resolving to 3 for every real featureset already. Having two FeatureGateAwareXValidation marker variants on the vcenters field (the pre-existing one and the new VSphereMultiVCenterDay2 one) plus the FeatureGateAwareMaxItems marker referencing the legacy VSphereMultiVCenters gate causes the feature-gated CRD manifest merge generator to non-deterministically drop validations depending on alphabetic file ordering between the VSphereMultiVCenters and VSphereMultiVCenterDay2 partial schemas. Hardcoding MaxItems=3 (matching upstream, where VSphereMultiVCenters has already been fully removed) avoids a second competing FeatureGateAwareXValidation-adjacent marker on this field and keeps the generated schema stable across TechPreviewNoUpgrade, DevPreviewNoUpgrade and CustomNoUpgrade.
Change the meta-schema used by the feature-gated CRD manifest merge generator so that the x-kubernetes-validations array is merged with list-type atomic instead of list-type map (keyed by rule). With the rule-keyed map strategy, two FeatureGateAwareXValidation marker variants with different CEL rule text (e.g. the pre-existing "vcenters cannot be added or removed once set" rule and the new VSphereMultiVCenterDay2-gated rules) are treated as distinct map entries and accumulate rather than the more specific, feature-gated variant replacing the default one. Using atomic ensures that whichever partial schema is merged last for a given feature set correctly replaces the whole validations list for that field. (cherry picked from commit 760409d)
Run make update to regenerate the CRD manifests, feature-gated CRD manifest snapshots, payload manifests, openapi and features.md to reflect the VSphereMultiVCenterDay2 changes and the vcenters MaxItems hardcoding, now that the manifest-merge schema correctly replaces x-kubernetes-validations per feature set instead of accumulating conflicting variants. The VSphereMultiVCenters feature-gated CRD manifest snapshot is removed since no type marker references that gate any longer (its MaxItems annotation was hardcoded away); the gate itself remains registered in features/features.go and payload-manifests/featuregates. (cherry picked from commit ea9f400)
…ions VSphereMultiVCenters is this release's leftover legacy feature gate for multi-vCenter support (already GA, enabled in Default); its dedicated integration test file is exercised against every feature set where the gate is enabled, including DevPreviewNoUpgrade, TechPreviewNoUpgrade and CustomNoUpgrade, all of which also enable VSphereMultiVCenterDay2. - Exclude VSphereMultiVCenterDay2 so this file only exercises the pre-Day2 behavior; once Day2 is active, adding/removing vCenters (including going straight from zero/partial vcenters to multiple) is intentionally allowed by the new Day2-specific validations, which contradicts what this file asserts. - Fix two tests that referenced a vcenter server name (vcs8e-vc.ocp2.dev.cluster.com) not matching any configured failure domain's server, which now trips the new "all failure domains must have a corresponding vCenter entry" validation. - Update the two tests that relied on the pre-existing "vcenters cannot be added or removed once set" validation still being enforced once the vcenters field also carries VSphereMultiVCenterDay2-gated validations: with two FeatureGateAwareXValidation variants now present on the same field, the default (featureGate="") variant is only generated for the fully-ungated manifest, so once a schema is regenerated for any other single feature gate the default variant is absent from that partial schema too. This matches upstream's shipped behavior for the equivalent field (see the Default feature set CRD manifest).
Cherry-pick of upstream d5e334d. The previous sort.Slice comparator was an invalid strict weak ordering, making partial-manifest merge order Go-toolchain-dependent: a regen built with go1.26 placed AAA_ungated.yaml after the gated partials, so the ungated values clobbered VSphereMultiNetworks maxItems=10 and the DualReplica enum. Regenerate infrastructures CRD manifests to restore the gated values. Co-Authored-By: Claude Code <noreply@anthropic.com>
openshift-ci-robot
added
the
jira/valid-reference
|
@vr4manta: This pull request references SPLAT-2868 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.19.z" version, but no target version was set. DetailsIn response to this:
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. |
|
Hello @vr4manta! Some important instructions when contributing to openshift/api: |
|
Pipeline controller notification This PR uses the pipeline controller for second-stage tests. Selection and triggering follow the repository configuration. Use |
openshift-ci
Bot
added
the
size/XXL
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configuration
You can disable this status message by setting the Use the checkbox below for a quick retry:
Comment |
|
/pipeline required |
|
Scheduling tests matching the |
|
@vr4manta: The following tests failed, say
Full PR test history. Your PR dashboard. DetailsInstructions 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. |
|
/approve |
openshift-ci
Bot
added
the
backport-risk-assessed
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: everettraven The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci
Bot
added
the
approved
|
/payload-job-with-prs periodic-ci-openshift-release-main-nightly-4.19-e2e-vsphere-ovn-zones-techpreview openshift/machine-api-operator#1590 openshift/installer#11024 openshift/cluster-cloud-controller-manager-operator#530 openshift/cluster-config-operator#531 |
|
@vr4manta: trigger 0 job(s) for the /payload-(with-prs|job|aggregate|job-with-prs|aggregate-with-prs) command |
SPLAT-2868
Changes
Notes
This PR is attempting to backport the following PRs:
There were also bugs that have not been ported back that fix CRD generation that have been included in this PR.