-
Epic
-
Resolution: Obsolete
-
Undefined
-
None
-
None
-
None
-
None
-
Failure Domains GA
-
False
-
None
-
False
-
Not Selected
-
Done
-
75% To Do, 0% In Progress, 25% Done
-
L
-
Follow-up of OSASINFRA-2998
Goal
Users can configure the fine-grained placement of masters and workers across Compute and Storage failure domains, as well as Neutron networks.
With this feature, users can define failure domains in the Installer install-config.yaml. Control plane failure domains can replace the default subnet for the machines, meaning that they can be placed on separate networks (the user must ensure routing). All failure domains can define additional networks, as well as Compute and Storage (root volume) availability zones where the corresponding machines will be attached.
In addition, Failure domain ports can be identified with a more flexible API (with network filters and subnet filters), and can define multiple subnets (in particular, to support IPv6).
These goals will be achieved through:
- a new `failureDomain` API structure, that allows to define:
- a primary (“control-plane”) port for masters in each Failure domain
- additional ports for machines in each Failure domain (for example, to assign a separate storage network to each failure domain)
- a Compute availability zone
- a Storage availability zone for the optional root volume
- the `failureDomain`structure will be used:
- in the Installer's install-config.yaml
- in the ControlPlaneMachineSet to allow managed vertical scaling.
Why is this important?
- to allow leveraging separate Neutron fault domains
- to allow integration with the new Cluster Control Plane Machine Set operator.
Scenarios
\
- ...
Acceptance Criteria
- CI - MUST be running successfully with tests automated
- Release Technical Enablement
- ...
Dependencies (internal and external)
- ...
Previous Work (Optional):
- …
Open questions::
- …
Done Checklist
- CI - CI is running, tests are automated and merged.
- Release Technical 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>