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

Localnet UDN blueprint

XMLWordPrintable

    • blueprint-localnet
    • Quality / Stability / Reliability
    • 77
    • Hide
      • The process is documented end to end
      • All the examples must be copy-pasteable unless there is a variable dependent on the environment
      • The blueprint has a matching T2 test
      • One diagram per topology (one for primary, one for secondary NICs)
      • (stretch) Pull manifests to tests straight from the doc sources
      Show
      The process is documented end to end All the examples must be copy-pasteable unless there is a variable dependent on the environment The blueprint has a matching T2 test One diagram per topology (one for primary, one for secondary NICs) (stretch) Pull manifests to tests straight from the doc sources
    • To Do

      Goal

      Document a recommended network setup for VMs. This should cover the process end to end, from planning and hardware requirements, through definition of the bonding, bridge, UDN, to its use from a VM and IP allocation.

      User Stories

      • As a user, I want to be given clear guide on best practices and end-to-end solutions for typical setups

      Non-Requirements

      • <List of things not included in this epic, to alleviate any doubt raised during the grooming process.>

      Notes

      • This can be either in our docs or in https://validatedpatterns.io/patterns/
      • There should be an intro to localnet, what is it good for, what are the best practices (use VLANs)
      • The localnet setup has these stages:
        • Once:
          • Planning (NICs, primary network or secondary, DHCP or no, flat network, VLAN trunk configured)
          • Creating bonding and a bridge (depending on the planning, this may be one of two ways, either with the day-1 installer for primary, or knmstate for secondary), defining the bridge mapping
          • Creating the CUDN (clearly explain that IPAM is no an option, and that all the fields set there are there for a reason)
        • Per each namespace:
          • Make sure the namespace has the correct label
        • Per each VM:
          • Connecting to the network
            • Bridge binding to that network
            • UI or YAML
            • Explain that VM is connected only to that one network, no need for Pod network
          • IPAM
            • Explain the options, set by the guest, through cloud init, DHCP
      • List caveats
        • No trunk, PVLAN, MAC spoof off
        • To get multiple connections to the same VLAN from a VM, multiple CUDNs must be used

          1.
          upstream roadmap issue Sub-task New Normal Unassigned
          2.
          upstream design Sub-task New Normal Unassigned
          3.
          upstream documentation Sub-task New Normal Unassigned
          4.
          upgrade consideration Sub-task New Normal Unassigned
          5.
          test plans in polarion Sub-task New Normal Unassigned
          6.
          automated tests Sub-task New Normal Unassigned
          7.
          downstream documentation merged Sub-task New Normal Unassigned

              phoracek@redhat.com Petr Horacek
              phoracek@redhat.com Petr Horacek
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated: