-
Epic
-
Resolution: Unresolved
-
Major
-
None
-
None
-
None
-
Determine Supported Network Layouts
-
False
-
-
False
-
Not Selected
-
To Do
-
100% To Do, 0% In Progress, 0% Done
-
S
OCP/Telco Definition of Done
Epic Template descriptions and documentation.
<--- Cut-n-Paste the entire contents of this description into your new Epic --->
Epic Goal
- Improve our definition of what can and cannot be supported in terms of network architectures.
Why is this important?
- As we have more, and more complicated, on-prem deployments some of our customers are attempting use network layouts that don't necessarily make sense and/or don't work with some components of OpenShift. Our existing documentation on network requirements is pretty minimal because it was targeted at cloud platforms where network architectures are, as a rule, simpler.
Scenarios
- As an OpenShift deployer, I want my nodes to have multiple nics on the same subnet as a sort of primitive bond.
- As an OpenShift deployer, I want my nodes to have multiple nics on different subnets in order to better separate different types of network traffic.
- As an OpenShift deployer, I want my worker nodes to be on different subnets to reflect the location of the physical hardware or to provide better segmentation of my network.
- As an OpenShift deployer, I want my master nodes to be on different subnets because...I'm not sure, actually. Maybe related to failure domains? In any case, I've seen this architecture in customer cases.
- As an OpenShift deployer, I want to change the IP of an existing node without reprovisioning it.
Acceptance Criteria
- CI - MUST be running successfully with tests automated
- Release Technical Enablement - Provide necessary release enablement details and documents.
- Documentation of the outcome of discussions around the various architectures listed above.
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>