Uploaded image for project: 'OpenShift Virtualization'
  1. OpenShift Virtualization
  2. CNV-28924

[GA] IPv6 single-stack for control plane and secondary networks

XMLWordPrintable

    • ga-ipv6-single-stack
    • Product / Portfolio Work
    • Hide
      • https://issues.redhat.com/browse/CNV-14598
      • Gain confidence from the tech preview
      • Any gaps compared to IPv4 / dual-stack deployments are documented
      • VM's connected to secondary localnet / bridge CNI / SR-IOV networks work as well as they do on IPv4 and dual-stack clusters
      • Make sure that it works end-to-end, including RHEL support
      • Drop the TP note from docs
      Show
      https://issues.redhat.com/browse/CNV-14598 Gain confidence from the tech preview Any gaps compared to IPv4 / dual-stack deployments are documented VM's connected to secondary localnet / bridge CNI / SR-IOV networks work as well as they do on IPv4 and dual-stack clusters Make sure that it works end-to-end, including RHEL support Drop the TP note from docs
    • Red
    • In Progress
    • VIRTSTRAT-510 - Single stack IPv6
    • VIRTSTRAT-510Single stack IPv6
    • 64% To Do, 18% In Progress, 18% Done
    • dev-ready, doc-ready, po-ready, px-ready, qe-ready, ux-ready
    • Hide

      2022-04-04: for awareness - trying to find a way to deploy single stack IPV6; moreover, currently we cannot deploy dual-stack (https://bugzilla.redhat.com/show_bug.cgi?id=2069374)...

      Show
      2022-04-04: for awareness - trying to find a way to deploy single stack IPV6; moreover, currently we cannot deploy dual-stack ( https://bugzilla.redhat.com/show_bug.cgi?id=2069374) ...

      Goal

      IPv6 single-stack for the control and secondary network data planes.

      User Stories

      • As a telco admin that is trying to move away from IPv4, I want to be able to use only IPv6 in my OCP cluster.

      Notes

      • This should cover OVN localnet, bridge CNI and SR-IOV. Overlay networks will be covered in a follow-up.
      • Existing lanes: All "ipv6" lanes, some are active, some less, some run a lot of tests, some a few. We need to get this under control. T1 seems in general good. T2 would need a lot of work.
      • Plan:
        • Prepare enablement materials so people from other components make an educated decision about which of their features may or may not be affected by IPv6.
        • Organize a regular sync for the component teams. Here we would present the epic, request others to share their input on requested test coverage, etc.
        • Based on those conversations, create an STP.
        • Have a spike, understand what is causing T2 to fail. Investigate whether we can adjust the infrastructure of our tests, so all of them to pass without further adjustments on the side of the component teams.
        • Negotiate the ownership of the downstream test lanes, which tests should run there, and how often.

      Owners

      Role Contact
      PM rsdeor
      Documentation Owner TBD
      Delivery Owner (See assignee)
      Quality Engineer (See QE Assignee)

      Done Checklist

      Who What Reference
      DEV Upstream roadmap issue https://github.com/kubevirt/kubevirt/issues/6732
      DEV Upstream code and tests merged https://github.com/kubevirt/kubevirt/pull/7158
      DEV Upstream documentation merged <link to meaningful PR>
      DEV gap doc updated <name sheet and cell>
      DEV Upgrade consideration N/A
      DEV CEE/PX summary presentation label epic with cee-training and add a <link to your support-facing preso>
      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>

              phoracek@redhat.com Petr Horacek
              rsdeor Ronen Sde-Or
              Yossi Segev Yossi Segev
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated: