"Once this is resolved, it should be possible to start a VM with cloud- init and metadata disabled, and then enable metadata some time later and have the boot process complete at that time."
That doesn't really make sense. And re-trying timing out in 10 seconds and re-trying wouldn't really change anything. Either you block the boot waiting for the other end of the read() or you don't. "have the boot process complete at that time" is I think what we have in precise and trusty right now. boot will hang until the read() came back. I'm not sure if upstart boot will actually wait forever on cloud-init-local to return , it may well do that. I suspect that systemd will kill cloud-init after like 90 seconds. Its very arguable that the *right* thing to do is wait forever on the metadata service. Cloud-init only knows what it should do next based on information from the metadata service. If this is the first boot of an instance, then some things will happen, if it is a reboot, then things such as ssh key generation or user creation will not occur. So this is *kind of* working by design. Sure we can change the setting to give up, but that will just result in cloud-init not finding a datasource. If that was a instance's first boot, then the user wouldn't be able to access the system. If it was any other boot, then things would be fine, but cloud-init has no way of knowing that this is "second boot" other than by the metadata service. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1667735 Title: cloud-init doesn't retry metadata lookups and hangs forever if metadata is down To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1667735/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
