Description of problem: Adding ipv6.dhcp-duid=ll means we get a predictable client ID so that reservations can be made on the DHCP server - this is useful if you want to provide the hostname via DHCP (although a reverse DNS lookup should also work) Reservations are also required to ensure the controlplane IP of the masters won't ever change post-deployment which will be necessary if the DNS lookup approach is taken to set the hostnames. - What I did Updated the NetworkManager configuration, only for the baremetal (IPI) platform, so we specify the ipv6.dhcp-duid=ll option. This enables a predictable (mac derived) client ID/DUID when deploying in an IPv6 environment. - How to verify it If testing with dev-scripts you can check via virsh net-dhcp-leases baremetal - on baremetal you can check the client ID in the lease for the nic connected to the controlplane network (/var/lib/NetworkManager/dhclient6*.lease) In both cases the controlplane network must be configured for single-stack ipv6, and there are some other PRs open to enable that e2e with the default OpenShift builds. openshift-metal3/dev-scripts#871 has some more details. - Description for the changelog Updated the NetworkManager configuration, for the baremetal (IPI) platform to specify the ipv6.dhcp-duid=ll option. This enables a predictable (mac derived) client ID/DUID.
cc: mcornea for possible QA; it looks like this IS legitimately testable in 4.4 even without working IPv6
Verified on 4.4.0-0.nightly-2020-02-07-203942: [root@worker-0 core]# cat /etc/NetworkManager/conf.d/99-kni.conf [main] dhcp=dhclient rc-manager=unmanaged [connection] ipv6.dhcp-duid=ll
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:0581