many: move network initialization to a separate service.

[mwhudson]

The default netplan config written by firstboot does not interact well with any
other config that gets written. So it should only be used if there is not any
other network config (thanks ConditionPathExistsGlob=!/etc/netplan/*.yaml) and
should not persist on the disk (so just write it to /run/netplan/ and delete it
immediately after use).

This all sounds great, but it doesn't work :/ (network doesn't come up on first
boot). Maybe one of you can see why -- it's time for my weekend.

[mwhudson]

So the reason this doesn't work is that something is deleting the config from /run/systemd/network/ after snap init-network runs. No idea what.

[mwhudson]

Oh well, it's netplan itself that's deleting the file. Tested by hacking in code to copy the /run/systemd/network/10-netplan-all.network that netplan generates to a file name that netplan won't clean up by itself when it runs again, and after boot that file is still there but the original has gone. So something else must be running netplan during the boot process. It's not the initial generate, the stamp file is present when my new service runs.

[martinpitt]

Yes, every time netplan generate runs it will remove existing /run/systemd/network/10-netplan* configs to avoid leaking previous config files when the config has changed. Do you remove /run/netplan/00-initial-config.yaml at some point? If so, then this should only be done when you write some actual config to `/etc/netplan/.

Note that the first time when systemd daemon-reload runs, netplan generate will also run; at that time /run/systemd/generator/netplan.stamp is created which will prevent daemon-reload from re-running netplan apply.

Can you please explain the bug in more detail?

[mvo5]

Fwiw, code looks fine.

[mwhudson]

Yeah, writing the config and then deleting it is clearly skating on thin ice. Ultimately there is going to be a single location for snapd / console-conf / cloud-init to put the network config (a field in the core snap's config), but until the config system materialises, lets just have them all write to the same location in /etc.