Comment 2 for bug 2008727

Thanks for reporting this Carlos.

Current recommendation for users with cloud-init installed manually on their local desktop for development is to manually create /etc/cloud/cloud-init.disabled, which will prevent cloud-init from doing the local discovery that caused this delay.

Prior to cloud-init release 23.1, cloud-init was running, however no datasource was detected so you didn't experience this delay. With the addition of support for OpenStack baremetal[1], your system is being detected as a potential datasource for OpenStack, which caused the delay. If openstack ironic has some way of identifying itself to cloud-init, we might be able to improve cloud-init by eliminating this false positive, however from the docs I've read I haven't seen seen anything that we can use.

> at a first glance it appears to be due cloud-init-local.service waiting for network activity in the Ethernet port, which I rarely use.

Agreed, cloud-init used the first fallback device, which looks like was a wireless device on the more successful subsequent (15s) timeouts. I'm curious why the fallback device changed. To help us with this, would you mind also including dmesg output of this system just after boot with cloud-init installed?

[1] https://github.com/canonical/cloud-init/commit/02202954c65a7a1cdb9b28703bd0af01edd0e091