Comment 34 for bug 1621507

Most definitely my comments above are with regard to SRU, because I know
that the point of this bug is to be SRU'd.

> d) is "unavoidable" if we're do make use of ROUNDTTT, and to be frank,
> seems like a reasonable side-effect. There's only so much that can be
> done to handle both IPv4 and IPv6 in the initramfs, and I think we can
> live we a few extra seconds booting. Furthermore, systems that do not
> get their IP addresses in the first few seconds probably deserve a good
> revision -- it is likely happening due to suboptimal network
> configuration (you shouldn't have to wait multiple seconds for the DHCP
> server to respond). In the case where there is no IPv4 available, it
> won't change the end result -- the system will still fail to boot, it
> will just take longer doing so (and on IPv6-only, people should set
> ip=off explicitly, and that use case was not previously supported).

How is not doing a 'sleep' unavoidable? The new code path only uses
dhclient in some cases for ipv4. In cases where it still allows the
ipconfig path (kernel command line of 'ip=dhcp') the initramfs will now
sleep in between re-tries when previously it would not.

It will take longer to boot, and that is a regression. It is definitely
fixable.

> In the context of an SRU, it seems like a better deal to cause things to
> take a little longer in the less used, deprecated method of using
> ipconfig than to change ipconfig parameters in a way that might cause

How are you "deprecate" ing this ? Can you show me where deprecating
behavior is allowed in an SRU?

> other issues (reducing the timeout generally, and using the sleep
> "alone" means systems that are genuinely slow might fail completely for
> no good reason. Making the timeout 2 seconds every time would yield to
> such an effect; whereas making the timeout 30 every time would lead to a
> substantial delay in bringing up the network if the first tries fail).

> b) I haven't seen a proper use case where this was important. There
> isn't straightforward way to set the hostname request for dhclient; and
> properly configuring the DHCP server would get you the right hostname.
> Furthermore, the hostname in use when enlisting or deploying MAAS
> systems should not matter, as it's the kind of information that should
> be written out to the final system (and doesn't matter on ephemeral,
> "get how many disks this machine has" instances -- the hostname there is
> already known and set by MAAS).

see bug 1069570 for a real world example (even affecting MAAS) of how a
hostname is important.
Something being "not straight forward" doesn't mean that you can just
regress behavior in an SRU. MAAS is not the only consumer of ipv4 dhcp
boot.

> a) A valid concern, but let's focus on making things work at all before
> optimizing. This should be verified in the devel release before a SRU.

> c) I don't know what it will do; it will need to be properly watched in
> SRUs and the devel release. My initial testing shows absolutely no
> adverse effects.

Did you ever boot a system and look? I suggest you need to account for
that and test and see what happens.