Uploaded image for project: 'On Prem Networking'
  1. On Prem Networking
  2. OPNET-26

Determine Supported Network Layouts

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Unresolved
    • Icon: Major Major
    • None
    • None
    • BM Networking
    • None
    • Determine Supported Network Layouts
    • False
    • Hide

      None

      Show
      None
    • 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

      1. As an OpenShift deployer, I want my nodes to have multiple nics on the same subnet as a sort of primitive bond.
      2. 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.
      3. 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.
      4. 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.
      5. 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)

      1. ...

      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>

              bnemec@redhat.com Benjamin Nemec
              bnemec@redhat.com Benjamin Nemec
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated: