OCPBUGS-105168: Add haproxyVersion in IngressController API

[jcmoraisjr]

Add haproxyVersion field in IngressController API. This field adds the ability to pin HAProxy to 2.8 before upgrade OpenShift to 5.0 or 4.23.

This is an API update only, there is no operator change in 4.22. The configured value is carried to the new OpenShift version, which will deploy HAProxy as specified.

EP: openshift/enhancements#1965

https://redhat.atlassian.net/browse/OCPBUGS-105168

[openshift-merge-bot]

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-robot]

@jcmoraisjr: This pull request references Jira Issue OCPBUGS-105168, which is invalid:

• release note text must be set and not match the template OR release note type must be set to "Release Note Not Required". For more information you can reference the OpenShift Bug Process.
• expected Jira Issue OCPBUGS-105168 to depend on a bug targeting a version in 5.0.0 and in one of the following states: MODIFIED, ON_QA, VERIFIED, but no dependents were found

Comment /jira refresh to re-evaluate validity if changes to the Jira bug are made, or edit the title of this pull request to link to a different bug.

The bug has been updated to refer to the pull request using the external bug tracker.

Details

In response to this:

Add haproxyVersion field in IngressController API. This field adds the ability to pin HAProxy to 2.8 before upgrade OpenShift to 5.0 or 4.23.

This is an API update only, there is no operator change in 4.22. The configured value is carried to the new OpenShift version, which will deploy HAProxy as specified.

EP: openshift/enhancements#1965

https://redhat.atlassian.net/browse/OCPBUGS-105168

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.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository YAML (base), Central YAML (inherited)

Review profile: CHILL

Plan: Pro Plus

Run ID: 7ac837cc-dd2d-408b-b88b-9e8970515377

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[openshift-ci]

Hello @jcmoraisjr! 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]

[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 deads2k 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:

• OWNERS

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

[qodo-for-rh-openshift]

PR Summary by Qodo

IngressController API: add haproxyVersion field for HAProxy pinning

✨ Enhancement ⚙️ Configuration changes 🕐 20-40 Minutes

AI Description

• Add spec.haproxyVersion to IngressController API to preserve HAProxy pin intent.
• Publish validation/docs via CRD, OpenAPI, and Swagger generation outputs.
• Clarify this is 4.22 API-only; operator behavior is honored post-upgrade.

Diagram

graph TD
  A["Cluster admin"] --> B["IngressController CR"] --> C["IngressControllerSpec (Go API)"] --> D["CRD schema (YAML)"] --> E["Kube API server"]
  C --> F["OpenAPI / Swagger"]
  E --> G["Future ingress operator (5.0+)"]

  subgraph Legend
    direction LR
    _u["User/Actor"] ~~~ _api["API Type"] ~~~ _cfg["Config/Schema"] ~~~ _svc["Service"]
  end

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Use an annotation to preserve HAProxy pin intent

• ➕ Avoids adding a new API field and regenerating CRDs/OpenAPI
• ➕ Potentially faster to backport without schema changes
• ➖ No schema/enum validation; easy to typo and silently lose intent
• ➖ Harder to document/discover; worse UX for API clients
• ➖ Less future-proof for GA behavior and tooling

2. Introduce a generic 'componentVersions' map in the API

• ➕ Could cover future pinning needs beyond HAProxy
• ➕ Single mechanism for multiple components
• ➖ Over-generalizes and increases API surface/ambiguity
• ➖ Harder validation and compatibility guarantees per component
• ➖ More review/maintenance burden than a targeted field

Recommendation: Keep the explicit spec.haproxyVersion API field with enum validation. It is discoverable, tool-friendly, and safely preserves upgrade intent without introducing operator-side behavior in 4.22, aligning with the stated 'API-only backport' goal.

Files changed (10) +179 / -0

Enhancement (1) +31 / -0

types_ingress.goAdd IngressControllerSpec.HAProxyVersion field and enum type +31/-0

Add IngressControllerSpec.HAProxyVersion field and enum type

• Introduces 'HAProxyVersion' on 'IngressControllerSpec' with documentation emphasizing it has no 4.22 runtime effect. Defines a dedicated 'HAProxyVersion' string type constrained to enum value "2.8" for 4.22.

operator/v1/types_ingress.go

Documentation (1) +1 / -0

zz_generated.swagger_doc_generated.goDocument haproxyVersion in generated Swagger docs +1/-0

Document haproxyVersion in generated Swagger docs

• Adds a SwaggerDoc entry for 'haproxyVersion' on IngressControllerSpec, mirroring the API-only backport semantics and allowed values for 4.22.

operator/v1/zz_generated.swagger_doc_generated.go

Other (8) +147 / -0

zz_generated.openapi.goExpose haproxyVersion in generated OpenAPI schema +7/-0

Expose haproxyVersion in generated OpenAPI schema

• Adds the 'haproxyVersion' property to the IngressControllerSpec OpenAPI definition, including detailed behavior notes for the 4.22 API-only backport and upgrade intent.

openapi/generated_openapi/zz_generated.openapi.go

0000_50_ingress_00_ingresscontrollers-CustomNoUpgrade.crd.yamlAdd haproxyVersion to CustomNoUpgrade CRD schema +20/-0

Add haproxyVersion to CustomNoUpgrade CRD schema

• Updates the generated CRD to include 'spec.haproxyVersion' with enum validation ("2.8") and the API-only/backport documentation block.

operator/v1/zz_generated.crd-manifests/0000_50_ingress_00_ingresscontrollers-CustomNoUpgrade.crd.yaml

0000_50_ingress_00_ingresscontrollers-Default.crd.yamlAdd haproxyVersion to Default CRD schema +20/-0

Add haproxyVersion to Default CRD schema

• Updates the default generated CRD manifest to publish the new 'haproxyVersion' field, including description and enum constraint.

operator/v1/zz_generated.crd-manifests/0000_50_ingress_00_ingresscontrollers-Default.crd.yaml

0000_50_ingress_00_ingresscontrollers-DevPreviewNoUpgrade.crd.yamlAdd haproxyVersion to DevPreviewNoUpgrade CRD schema +20/-0

Add haproxyVersion to DevPreviewNoUpgrade CRD schema

• Adds 'spec.haproxyVersion' schema entry with enum validation and documentation to the DevPreviewNoUpgrade CRD variant.

operator/v1/zz_generated.crd-manifests/0000_50_ingress_00_ingresscontrollers-DevPreviewNoUpgrade.crd.yaml

0000_50_ingress_00_ingresscontrollers-OKD.crd.yamlAdd haproxyVersion to OKD CRD schema +20/-0

Add haproxyVersion to OKD CRD schema

• Publishes the 'haproxyVersion' field in the OKD CRD manifest, maintaining the same enum constraint and descriptive guidance.

operator/v1/zz_generated.crd-manifests/0000_50_ingress_00_ingresscontrollers-OKD.crd.yaml

0000_50_ingress_00_ingresscontrollers-TechPreviewNoUpgrade.crd.yamlAdd haproxyVersion to TechPreviewNoUpgrade CRD schema +20/-0

Add haproxyVersion to TechPreviewNoUpgrade CRD schema

• Adds the new field to the TechPreviewNoUpgrade CRD variant so the schema is consistent across build flavors.

operator/v1/zz_generated.crd-manifests/0000_50_ingress_00_ingresscontrollers-TechPreviewNoUpgrade.crd.yaml

AAA_ungated.yamlAdd haproxyVersion to ungated featuregated CRD output +20/-0

Add haproxyVersion to ungated featuregated CRD output

• Updates the featuregated CRD output to include 'haproxyVersion' with enum validation and the same API-only backport documentation.

operator/v1/zz_generated.featuregated-crd-manifests/ingresscontrollers.operator.openshift.io/AAA_ungated.yaml

IngressControllerDynamicConfigurationManager.yamlAdd haproxyVersion to dynamic configuration manager CRD output +20/-0

Add haproxyVersion to dynamic configuration manager CRD output

• Propagates the new 'haproxyVersion' schema to this featuregated CRD output to keep generated schemas aligned.

operator/v1/zz_generated.featuregated-crd-manifests/ingresscontrollers.operator.openshift.io/IngressControllerDynamicConfigurationManager.yaml

[qodo-for-rh-openshift]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (1) 📜 Skill insights (0)

1. HAProxyVersion missing FeatureGate marker 📘 Rule violation § Compliance

Description

A new stable API field HAProxyVersion was added to IngressControllerSpec without an adjacent
+openshift:enable:FeatureGate=<name> marker. This makes the new field ungated in a stable API,
violating the requirement to feature-gate new stable API fields.

Code

operator/v1/types_ingress.go[R405-406]

+	// +optional
+	HAProxyVersion HAProxyVersion `json:"haproxyVersion,omitempty"`

Relevance

●●● Strong

Repo commonly feature-gates new operator/v1 fields; missing marker likely fixed to meet API
conventions.

PR-#2537
PR-#2947

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance ID 185 requires every newly added field in stable API structs to have a
+openshift:enable:FeatureGate=<FeatureGateName> marker immediately above the field. In
IngressControllerSpec, the newly added HAProxyVersion field is preceded by +optional but has
no +openshift:enable:FeatureGate=... marker.

Rule 185: Gate new fields in stable APIs with +openshift:enable:FeatureGate marker
operator/v1/types_ingress.go[389-406]

Agent prompt

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

## Issue description
A new stable API field (`HAProxyVersion` / `haproxyVersion`) was added to `operator/v1` without the required `+openshift:enable:FeatureGate=<FeatureGateName>` marker placed directly above the field.

## Issue Context
Stable API fields must be gated with `+openshift:enable:FeatureGate=...` to control rollout and compatibility. The marker must be immediately adjacent to the new field declaration.

## Fix Focus Areas
- operator/v1/types_ingress.go[389-406]

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

---

2. OpenAPI enum omitted 🐞 Bug ≡ Correctness

Description

HAProxyVersion is intended to be an enum (CRD enforces it), but it lacks the +enum marker, so
the generated OpenAPI schema exposes haproxyVersion as an unconstrained string. This makes
OpenAPI/Swagger-driven tooling (docs, generated clients, client-side validation) disagree with what
the API server will actually accept via CRD validation.

Code

operator/v1/types_ingress.go[R2312-2313]

+// +kubebuilder:validation:Enum="2.8"
+type HAProxyVersion string

Relevance

●●● Strong

OpenAPI/CRD schema consistency issues are typically corrected; adding enum marker is low-risk and
improves tooling.

PR-#2537

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The CRD manifests enforce an enum for haproxyVersion, but the generated OpenAPI schema does not
include an Enum list for that property. In contrast, a nearby enum type that includes the +enum
marker (IngressControllerConfigurationManagement) results in an OpenAPI property with an explicit
Enum list, indicating the missing marker is the cause of the OpenAPI omission for the new type.

operator/v1/types_ingress.go[2308-2314]
operator/v1/types_ingress.go[2122-2128]
operator/v1/zz_generated.crd-manifests/0000_50_ingress_00_ingresscontrollers-Default.crd.yaml[895-914]
openapi/generated_openapi/zz_generated.openapi.go[56187-56192]
openapi/generated_openapi/zz_generated.openapi.go[56389-56395]

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 new `HAProxyVersion` type is validated via CRD enum generation, but the generated OpenAPI (`zz_generated.openapi.go`) does not advertise the enum constraint for `haproxyVersion`. In this repo, OpenAPI enum emission is triggered by the `// +enum` marker on the Go type (see existing enum types).

### Issue Context
- CRD manifests already contain `enum: ["2.8"]`, so the API server will reject other values.
- OpenAPI currently renders `haproxyVersion` as `type: string` without an enum list.

### Fix
1. Add `// +enum` above `type HAProxyVersion string` (consistent with other enum types in this file).
2. Re-run the generators to update:
  - `openapi/generated_openapi/zz_generated.openapi.go`
  - `operator/v1/zz_generated.swagger_doc_generated.go` (if impacted)
  - CRD manifests (should remain consistent)

### Fix Focus Areas
- operator/v1/types_ingress.go[2308-2314]
- openapi/generated_openapi/zz_generated.openapi.go[56187-56193]

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

---

Context used

⚠️ Tickets: not configured — ticket URL found in PR but could not be fetched — check ticket provider credentials

✅ Compliance rules (platform): 29 rules

✅ Skills: api-review

_{To customize comments, go to the Qodo configuration screen, or learn more in the docs.}

[qodo-for-rh-openshift]

1. haproxyversion missing featuregate marker 📘 Rule violation § Compliance

A new stable API field HAProxyVersion was added to IngressControllerSpec without an adjacent
+openshift:enable:FeatureGate=<name> marker. This makes the new field ungated in a stable API,
violating the requirement to feature-gate new stable API fields.

Agent Prompt

## Issue description
A new stable API field (`HAProxyVersion` / `haproxyVersion`) was added to `operator/v1` without the required `+openshift:enable:FeatureGate=<FeatureGateName>` marker placed directly above the field.

## Issue Context
Stable API fields must be gated with `+openshift:enable:FeatureGate=...` to control rollout and compatibility. The marker must be immediately adjacent to the new field declaration.

## Fix Focus Areas
- operator/v1/types_ingress.go[389-406]

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

[qodo-for-rh-openshift]

2. Openapi enum omitted 🐞 Bug ≡ Correctness

HAProxyVersion is intended to be an enum (CRD enforces it), but it lacks the +enum marker, so
the generated OpenAPI schema exposes haproxyVersion as an unconstrained string. This makes
OpenAPI/Swagger-driven tooling (docs, generated clients, client-side validation) disagree with what
the API server will actually accept via CRD validation.

Agent Prompt

### Issue description
The new `HAProxyVersion` type is validated via CRD enum generation, but the generated OpenAPI (`zz_generated.openapi.go`) does not advertise the enum constraint for `haproxyVersion`. In this repo, OpenAPI enum emission is triggered by the `// +enum` marker on the Go type (see existing enum types).

### Issue Context
- CRD manifests already contain `enum: ["2.8"]`, so the API server will reject other values.
- OpenAPI currently renders `haproxyVersion` as `type: string` without an enum list.

### Fix
1. Add `// +enum` above `type HAProxyVersion string` (consistent with other enum types in this file).
2. Re-run the generators to update:
   - `openapi/generated_openapi/zz_generated.openapi.go`
   - `operator/v1/zz_generated.swagger_doc_generated.go` (if impacted)
   - CRD manifests (should remain consistent)

### Fix Focus Areas
- operator/v1/types_ingress.go[2308-2314]
- openapi/generated_openapi/zz_generated.openapi.go[56187-56193]

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

[openshift-ci]

@jcmoraisjr: 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/verify-hypershift-integration	98a192e	link	true	/test verify-hypershift-integration

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.