-
Epic
-
Resolution: Unresolved
-
Critical
-
None
-
None
-
[aws] Allow choose dedicated subnet for load balancers on install time
-
Strategic Product Work
-
8
-
False
-
None
-
False
-
Not Selected
-
To Do
-
OCPSTRAT-569 - Add ability to choose subnet while creating ingress controller of type LoadBalancerService
-
80% To Do, 0% In Progress, 20% Done
Epic Goal
SPLAT will be working in a consultative capacity in the effort to add the ability to choose subnets used by Load Balancers, Kube API and ingresscontroller of LoadBalancerService type.
This proposed details of the work to be performed is tracked in https://github.com/openshift/enhancements/pull/1634.
SPLAT has an open spike (SPLAT-1957) to track investigation activities that EP 1634 to cover RFE-4738.
Why is this important?
Currently, when installing a cluster the installer and IngressController/CCM uses the same subnets, making all FrontendIPs exposed to the same subnet as hosts.
However, the LoadBalancer Service implementation allows specifying the target subnet through service annotation. Therefore the need to introduce an additional field to the ingresscontroller CRD, that allows to specify the target subnets used by dedicated for load balancer on install-config.yaml.
The value of this field is then used to:
- make the installer which subnet the cluster provisioning will use to create Load Balancers. The need for this feature is additionally expressed in https://issues.redhat.com/browse/RFE-4738. and proposed in the EP comment https://github.com/openshift/enhancements/pull/1634#discussion_r1882061148
- annotate the created LoadBalancer Service from the beginning on, so the ingress controller immediately gets its FrontendIP into the right subnet.
Acceptance Criteria
- Enhancement Proposal is reviewed and approved
Dependencies (internal and external)
- ...
Previous Work (Optional):
- …
Open questions::
- …
Done Checklist
- CI - CI is running, tests are automated and merged.
- Release Enablement <link to Feature Enablement Presentation>
- DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
- DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
- DEV - Downstream build attached to advisory: <link to errata>
- QE - Test plans in Polarion: <link or reference to Polarion>
- QE - Automated tests merged: <link or reference to automated tests>
- DOC - Downstream documentation merged: <link to meaningful PR>