Comment 13 for bug 1677668

First of all thanks Jay for the great in depth extra-insight!

As Sam added, Cloud-Init can't do a lot here since it doesn't get a config to this stage.
The only thing it could consider to do is unconditionally always trigger a GARP.

But that would be:
1. offending the cloud-init design which is that it is supposed to do what it is told (not more not less)
2. add the dependency to a tool like arping for the image so that cloud-init can issue the GARP

So one step back - implementation in dhclient as-is as script:
1. this would still have to be unconditionally, but at least be bound to dhcp
2. it would have the same need for arping (or similar) in the image
  2.1 an alternative to the dependency would be to re-implement, but redundancy always is worse

I wonder if the following would be an option:
You already get your IP address, so you get your dhcp reply; Just the environment doesn't realize you moved. IIRC dhcp can transport extra options, so to get rid of the "unconditional" thing. Could dhcp grow a feature to understand a "dhcp-please-garp" option? Handling this option could be done in a dhclient script then. And on the other side the MAAS dhcp server could present this option.

That at least would make it
1. conditionally only where requested
2. maas has the control since it is the dhcp
3. not affect environments where things are not providing this option (for SRU-ability)

Making the cloud-init a wishlist item, since it seems a feature request more than a bug there and also as outlined above not really fixable there. Instead adding a dhclient task.

All of this has to consider, will more of systemd-networkd replace dhclient? If so considerations have to be made for that or it will regress as soon as things are switched.