For your other questions: > Did you have any specific reasoning to not implement an escape hatch to this infinite loop? Is it extra risk? Was it deemed unlikely, as clouds would "never" have the metadata service return 503 for too long? Or did you consider a stuck instance in a retry loop better than one that has booted, but that nobody can likely log into?
The main reason for me is it being unlikely in that I wouldn't expect an IMDS to be returning 503s for very long. But the other issue with timeouts is knowing what's reasonable. 5 seconds? 30 seconds? 10 minutes? 10 hours? Brett has talked about using cloud-init in HPC environments in which machines can take server hours to boot, with much of that time waiting for network congestion. Given the numerous places cloud-init exists, it's hard to determine what a reasonable escape hatch would be that can apply across all different environments. > Is the imds service the only way an instance can get its configuration? Would there be a scenario where cloud-init would be getting its config via something else, but still reach out to the metadata service, and halt boot if the metadata service is ill even though it could already be getting its config via that other method? There are a few cases where cloud-init looks for a local file or temporary drive, and if that doesn't exist goes to IMDS. The only case I can think of where IMDS is complementing another configuration is on Oracle where secondary IP information can be retrieved from IMDS after retrieving the primary information from the local iSCSI disk. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2094858 Title: Cloud-init fails on AWS if IMDSv2 returns a 503 error. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/2094858/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
