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

[U/S] DNS for secondary networks

XMLWordPrintable

    • dp-dns-for-secondary-networks
    • Hide
      • VMs connected through a secondary networks can be addressed (from the outside) by their domain names
      • This feature can be enabled/disabled by the user
      • We must not touch external DNS
      • DNS admin may be required to add some new records, but not many (not as many as there are interfaces)
      • U/S user-guide
      • D/S test automation
      • IPv4 only
      • DNS is not required for communication inside the cluster
      • No UXD
      Show
      VMs connected through a secondary networks can be addressed (from the outside) by their domain names This feature can be enabled/disabled by the user We must not touch external DNS DNS admin may be required to add some new records, but not many (not as many as there are interfaces) U/S user-guide D/S test automation IPv4 only DNS is not required for communication inside the cluster No UXD
    • Green
    • Done
    • 0% To Do, 0% In Progress, 100% Done
    • dev-ready, doc-ready, po-ready, px-ready, qe-ready, ux-ready
    • Hide

      2022-11-28: On track, basic functionality was demoed, repo was moved under kubevirt org, working on e2e tests. Not bound to the feature freeze...

      Show
      2022-11-28: On track, basic functionality was demoed, repo was moved under kubevirt org, working on e2e tests. Not bound to the feature freeze...

      Goal

      Allow VMs connected through their secondary networks to be addressable by their domain names.

      User Stories

      • As a developer,
        I want to address machines in the network using their domain names,
        so I don't rely on IP addresses specific to given environment.
        For example, something like ping -4 interfacename.vmname.namespace.vm.clustername.domainname should resolve to the relevant IP address.
        I would not mind if ping -4 interfacename.podname.namespace.pods.clustername.domainname works, too.
      • As a developer,
        I want this feature to be opt-in per interface,
        since not all interfaces are available from the outside, or meant to be used by clients.

      Non-Requirements

      • <List of things not included in this epic, to alleviate any doubt raised during the grooming process.>
      • It is expected that the secondary network is already available to the client

      Notes

      • An implementation may require the cluster-admin to request a NS entry in the organizational DNS, delegating name resolution of vms.clustername.domainname to the API IP address of the cluster, where CoreDNS would be running.
      • We could also consider doing it for internal secondary network
      • This should work for L3 (unlike services)

      Planning

      • OpenShift documents usage of the DNS server
      • Start by trying out examples from the docs
      • See if Kubernetes has the same and we can test it on Kubernetes

      Main plan:
      0. Ask around (Oren Cohen) how was the version explorer registered to the DNS: http://cnv-version-explorer.apps.cnv.engineering.redhat.com/
      1. See if external DNS is available in Kubernetes
      2. Bring up a OpenShift/Kuberneter cluster to test it on
      3. Test it with regular Pod network services we know work today
      4. Plug in our own IP and name there

      Alongside:

      • Research tools for DNS debugging, check the flow, DNS server, ...
      • Research how DNS servers are configured

      Q&A

      • Addressable from outside the cluster? - Yes
      • From inside the cluster? - This is secondary, nice to have
      • Will be pod network connected? - Not a must
      • Cluster DNS or outside? - Customer does not care

      Owners

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

      Done Checklist

      Who What Reference
      DEV Upstream roadmap issue None
      DEV Upstream code and tests merged https://github.com/kubevirt/kubesecondarydns
      DEV Upstream documentation merged https://github.com/kubevirt/kubesecondarydns#readme
      DEV gap doc updated Not relevant
      DEV Upgrade consideration None
      DEV CEE/PX summary presentation No downstream
      QE Test plans in Polarion No QE
      QE Automated tests merged No QE
      DOC Downstream documentation merged No downstream

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

                Created:
                Updated:
                Resolved: