it seems netlink routing table messages are more of a notifications of
changes being explicitly made vs notifications of all changes to
routing.
for https://bugs.launchpad.net/subiquity/+bug/1837822
my best guess at why CI is currently hanging sometimes is that the
'next-screen' signal is being sent too often / too early. add some
logging around this so that we will be able to confirm / deny this by
reading the logs.
Mark all devices with DHCP enabled as pending when the config is
applied, and mark them as timed out ten seconds later if they have not
received any addresses.
The main thrust of this is to not create virtual interfaces until
applying the config.
This meant that the network model has to change a bit to be able to
represent interfaces that do not yet exist on the system. I did this
by ripping out most of the existing network device code: now a
NetworkDev is really just a wrapper for the config for a device and (if
it exists) the netlink data too. A few places had to adjust to checking
if the netlink info is available before accessing it but all in all it
was not that painful.
There are a few other refactorings in this commit that perhaps should be
split out (how the bond parameters are handled, some stuff about
resizing the table rows when interfaces are edited) but it doesn't
really seem worth it.
When user configures network with subiquity, it's rendered
netplan should be wholly definitive. So, we remove the other files
that may have config. This fixes a bug where running in an instance
when running on a system where cloud-init had rendered a 'match' with
'macaddress'.
When writing netplan we keep 'macaddress' match in place but drop
others. The others may just wildcard from the installer environment,
but macaddress are likely by cloud-init or otherwise intentionally
written.
Also add an atomic write in subiquitycore/file_util and move the
netplan code into subiquitycore/netplan.py, and add some unit test
helpers from cloud-init.
read title and footer from the view instance, make views respsonsible for rendering
the excerpt
adapts infrastructure, welcome, keyboard, network views
the only really visible effect of all this is to make --dry-run
--machine-config foo show the network config from foo, not the machine
running subiquity. (The existing configs won't work, though)