Comment 14 for bug 1737630

Sure, and image is configured to use cloud-init with netplan backend, which itself uses networkd backend.

Now, the issues is that of a systemd boot transaction and inability to affect it whilst its in flight.

Thus netplan ships a generator, which on boot at generator stage (prior to calculating and executing the initial transaction) reads netplan.yaml configs and generates appropriate dependencies for a particular backend to be invoked.

Similarly cloud-init ships a generator, to hookup all the cloud-init units & targets into the initial transaction.

The problem is the one of the integration of the two generators.

cloud-init at generator stage, potentially knows, that it will spit out netplan configs & will generate netplan units *just in time* for the networking.target to have all the files on disk to have the right things.

But netplan at generator stage, sees no configs whats so ever, doesn't know which backend to use & hook up for the boot target, and thus does nothing. When cloud-init calls netplan to generate just in time units, netplan does generate dependencies to start the right networking backend, but it's too late as the initial boot transaction is already in progress and cannot be changed to slot in systemd-networkd & systemd-networkd-wait-online to bring up the networking.

It feels like there should be some integration between cloud-init & netplan generators to indicate that "yes we will have networking config" and "please hookup <default>, networkd, NetworkManager backends for the networking.target"