I have reviewed this. +1 from ~ubuntu-sru.
Regression risk is mitigated as Scott says by careful gating of the
active code to limit exposure of these changes to the non-default use
case only.
I did note the following:
What happens when the DHCP lease acquired in the initramfs expires? What
if the DNS server changes after a new lease? Really it's the entire DHCP
lease that needs handing over from the initramfs rather than just the
DNS server that was provided at the time of the first lease on boot. But
this will only affect this impacted non-default use case. If this
doesn't matter for you, then fine. If it does, then please mark
verification-failed and we can go again with a fix that will cover this
case.
If not on systemd and inside a container, check will not work. We don't
support !systemd on Ubuntu, so that should be OK. We may be on upstart
after upgrading from Trusty; in that case the /proc/cmdline gate should
still work so this will only affect systems booted this way using MAAS
on Trusty and then upgraded to Xenial until next reboot.
Adding a udev rule that is a shell script for every network up and down.
How does this effect udev, for example on a system with a large number
of flapping interfaces? On a quick glance I didn't see any other shell
script udev rule on such a wide reaching trigger.
Any race conditions before is-from-initrd gate, for example if multiple
interfaces come up close together in time? I don't see any.
Please make sure to test that the gating is working correctly in the
non-kernel-cmdline case during SRU verification.
** Changed in: resolvconf (Ubuntu Xenial)
Status: Confirmed => Fix Committed
** Tags added: verification-needed verification-needed-xenial
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711760
Title:
[2.3] resolv.conf is not set (during commissioning or testing)
To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1711760/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
