cloud-init-dev team mailing list archive

[Dimitri John Ledkov <launchpad@xxxxxxxxxxxx>]

I don't like this, as this will introduce a boot delay and total time to first boot for everybody, even if not strickly needed.

E.g. cloud-init may have networking config disabled (like it is on some agent managed clouds); clouds that don't do network things in cloud-init-local do not neeed this. Nor one needs this if the networking devices are initialized by now.

There are APIs such that one can query, if the network interfaces names are all there, and if they have been processed by udev and hence are renamed into a final name / ready.

One could connect to netlink/udev and check that things are finalized. And at that point one could have an asyncio loop to await for the states to be finalized. Or in a more functional style, call a blocking trigger settle on the net subsystem. But only do this at the point were one reached the decision point to start doing stuff based on the interface names and realized that they are nonfinal.

Also, if the names maybe getting renamed, the ifindexes will not. So a lot of early userspace code that does things to networks does so by ifindex instead, if that is sufficient for the things done there.

ps. I am assuming that there are datasources for which correct and valid network config is generated, based on datasource expectations irrespective if the names are ready or not. If there is no common-case datasource that does this, things may be different.
-- 
https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/344198
Your team cloud-init commiters is requested to review the proposed merge of ~raharper/cloud-init:fix/lp-1766287-run-after-udev-settle-service into cloud-init:master.