NE-2215: add enhancement for selectable HAProxy version#1965
NE-2215: add enhancement for selectable HAProxy version#1965jcmoraisjr wants to merge 1 commit intoopenshift:masterfrom
Conversation
This enhancement proposes adding the ability for cluster administrators to select specific HAProxy versions for IngressControllers, decoupling HAProxy version upgrades from OpenShift cluster upgrades. Supports current release and up to 2 previous releases to facilitate LTS-to-LTS migrations. Jira: https://redhat.atlassian.net/browse/NE-2215 Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
openshift-ci-robot
added
the
jira/valid-reference
|
@jcmoraisjr: This pull request references NE-2215 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 epic to target either version "4.22." or "openshift-4.22.", but it targets "openshift-5.0" instead. 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. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
|
||
| This enhancement modifies an existing CRD (IngressController) but does not | ||
| add webhooks or aggregated API servers. The existing SLIs for | ||
| IngressController resources apply: |
There was a problem hiding this comment.
Wondering if having a webhook instead is preferable, denying any attempt for an invalid requests. It needs a webhook since that in the current proposal the validation changes on every OpenShift release.
|
@jcmoraisjr: The following test 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. |
|
|
||
| ### Implementation Details/Notes/Constraints | ||
|
|
||
| The implementation requires the following high-level code changes: |
There was a problem hiding this comment.
Missing high-level comment about the approaches to package HAProxy and isolate its dynamic dependencies. Wondering if it fits here to comment all the possibilities, choosing one of them later when starting to implement.
|
/assign |
davidesalerno
left a comment
davidesalerno
left a comment
There was a problem hiding this comment.
The EP is quite good, but I've got some question that I hope will help to increase the level of details of some crucial points
| 3. The ingress-controller-operator validates the requested version is | ||
| available and supported. | ||
| 4. The operator updates the IngressController deployment to use the | ||
| specified HAProxy version and its matching dependencies. |
There was a problem hiding this comment.
I suggest to specify in a better way how we would like to manage this point.
The Cluster Ingress Operator today selects a single router image, not a HAProxy version, so there will be different options:
- one router image containing multiple HAProxy builds,
- multiple router images selected per IngressController,
- or a sidecar/init-container/artifact injection model
The EP should describe with a higher level of detail this point
| - Allowing selection of arbitrary HAProxy versions not shipped with | ||
| supported OpenShift releases | ||
| - Providing version selection for other ingress components beyond HAProxy | ||
| itself (router code, templates, etc.) |
There was a problem hiding this comment.
Are we saying that together with HAProxy we will select the corresponding router and config template?
Because otherwise there could be some issue if we change only the HAProxy version.
| // +optional | ||
| // +kubebuilder:default="Current" | ||
| // +openshift:enable:FeatureGate=SelectableHAProxyVersion | ||
| HAProxyVersion string `json:"haproxyVersion,omitempty"` |
There was a problem hiding this comment.
I think that a free-form string with comments saying valid values are "Current" and "OCP-X.Y" could be not enough. I'll add at least:
Patternvalidation for the accepted forms,- a corresponding status field that reports effective and requested values separately.
| - Specific versions are preserved if available in the target release | ||
| - Fall back to default if a version becomes unsupported when | ||
| Downgrading | ||
| - Deny cluster upgrades when any IngressController references a |
There was a problem hiding this comment.
Related to this point I've got the following questions:
- Which component sets Upgradeable=False?
- What exact reason/message?
- How is the target release computed?
- What is the skew behavior during a partially rolled out update?
- Why is downgrade fallback acceptable but upgrade denial required?
3 participants
This enhancement proposes adding the ability for cluster administrators to select specific HAProxy versions for IngressControllers, decoupling HAProxy version upgrades from OpenShift cluster upgrades. Supports current release and up to 2 previous releases to facilitate LTS-to-LTS migrations.
Jira: https://redhat.atlassian.net/browse/NE-2215