• bug is open, matching expected state (open)
• bug target version (4.22.0) matches configured target version for branch (4.22.0)
• bug is in the state POST, which is one of the valid states (NEW, ASSIGNED, POST)

In response to this:

RouteExternalCertificate is enabled by default, this is the second half of the changes to remove it and should be merged only after openshift/cluster-ingress-operator#1355 being merged.

Jira: https://issues.redhat.com/browse/OCPBUGS-74511

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.

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

• Remove RouteExternalCertificate feature gate completely
• Update feature gate definitions across all deployment profiles
• Clean up generated OpenAPI and feature documentation
• Simplify feature flag configuration by removing deprecated gate

Remove RouteExternalCertificate gate definition

features/features.go

Update feature documentation

features.md

Regenerate OpenAPI definitions

openapi/generated_openapi/zz_generated.openapi.go

Description

• RouteExternalCertificate was removed from the FeatureGate payload manifests (and the features
 registry), but the route API still declares fields/validations behind RouteExternalCertificate and
 the repo still carries generated featuregated CRD metadata and integration tests for it.
• This inconsistency makes the feature’s actual enablement unclear: clusters can no longer enable
 the gate via FeatureSet manifests, yet API schema/tests/docs still treat it as a live feature gate.
• Result is high risk of confusing behavior (feature appears supported in API artifacts but is not
 enable-able via cluster FeatureGates), and ongoing maintenance burden (stale tests/docs).

Code

payload-manifests/featuregates/featureGate-Hypershift-Default.yaml[L320-322]

- {
- "name": "RouteExternalCertificate"
- },

Evidence

The FeatureGate payload manifests no longer list RouteExternalCertificate as enabled/disabled, but
the route API and generated/test artifacts still reference it as an active feature gate. That
mismatch strongly suggests the repo is only partially updated: configuration-level enablement was
removed, but API gating and associated generated/test/doc artifacts weren’t cleaned up or migrated.

payload-manifests/featuregates/featureGate-Hypershift-Default.yaml[317-323]
payload-manifests/featuregates/featureGate-SelfManagedHA-Default.yaml[315-323]
route/v1/types.go[422-480]
route/v1/zz_generated.featuregated-crd-manifests.yaml[1-10]
route/v1/tests/routes.route.openshift.io/RouteExternalCertificate.yaml[1-6]
README.md[55-82]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
`RouteExternalCertificate` is removed from FeatureGate payload manifests / registration, but the route API and generated/test/doc artifacts still treat it as an active feature gate. This leaves the repo in an inconsistent state where the gate appears to exist for API gating/tests/docs, but is not enable-able via FeatureSet manifests.
## Issue Context
Evidence shows:
- FeatureGate manifests no longer include `RouteExternalCertificate`.
- Route API types still declare `ExternalCertificate` behind `+openshift:enable:FeatureGate=RouteExternalCertificate` and have FeatureGate-aware validation for it.
- Generated featuregated CRD metadata and integration tests still reference `RouteExternalCertificate`.
- README still uses it as the canonical example.
Decide intended outcome:
- **If the feature gate is being retired**: remove/ungate the API markers and delete/regenerate featuregated CRD/test/doc references.
- **If the feature gate is still intended to be supported**: restore FeatureGate registration + payload-manifest entries.
## Fix Focus Areas
- payload-manifests/featuregates/featureGate-Hypershift-Default.yaml[317-323]
- payload-manifests/featuregates/featureGate-SelfManagedHA-Default.yaml[315-323]
- route/v1/types.go[422-480]
- route/v1/zz_generated.featuregated-crd-manifests.yaml[1-10]
- route/v1/tests/routes.route.openshift.io/RouteExternalCertificate.yaml[1-6]
- README.md[55-82]
- features/features.go[150-170]

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

Description

• RouteExternalCertificate remains in legacyFeatureGates allowlists used to bypass enhancement-PR
 enforcement for ‘legacy’ gates.
• After removing the gate from the FeatureGate catalog/FeatureSets, keeping it in the allowlist
 makes it easier to accidentally reintroduce the gate without an enhancement link and obscures which
 gates are actually supported.
• This is a maintainability/process risk: it weakens the guardrail intended to prevent new,
 undocumented feature gates.

Code

features/features.go[L158-164]

-	FeatureGateRouteExternalCertificate = newFeatureGate("RouteExternalCertificate").
-						reportProblemsToJiraComponent("router").
-						contactPerson("chiragkyal").
-						productScope(ocpSpecific).
-						enhancementPR(legacyFeatureGateWithoutEnhancement).
-						enableIn(configv1.Default, configv1.OKD, configv1.DevPreviewNoUpgrade, configv1.TechPreviewNoUpgrade).
-						mustRegister()

Evidence

The repo still treats RouteExternalCertificate as a legacy gate in two different allowlists. Those
allowlists are explicitly used as a bypass when a feature gate registers with the
legacy/no-enhancement marker. Once the gate is removed elsewhere, leaving it in the allowlist is
inconsistent and reduces protection against accidental reintroduction.

features/legacyfeaturegates.go[84-90]
payload-command/render/legacyfeaturegates.go[88-95]
features/util.go[128-133]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
`RouteExternalCertificate` remains on the legacy feature gate allowlists even though the PR removes the gate from the FeatureGate catalog/FeatureSets. These allowlists are used to bypass enhancement PR enforcement, so keeping a removed gate there weakens the guardrail and increases risk of accidental reintroduction.
## Issue Context
`legacyFeatureGates` is explicitly used when `enhancementPRURL == legacyFeatureGateWithoutEnhancement` to decide whether a gate may bypass the enhancement requirement.
## Fix Focus Areas
- features/legacyfeaturegates.go[84-90]
- payload-command/render/legacyfeaturegates.go[88-95]
- features/util.go[128-133]

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

In response to this:

Marking this PR as verified as this openshift/cluster-ingress-operator#1355 (comment)
/verified by @mjoseph

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.