Fix DNS resolution performance regression during cloud-init local

[drzee99]

Fix DNS resolution performance regression during cloud-init local

Summary

This PR addresses critical DNS resolution performance issues during the early cloud-init local stage that cause boot delays of 2+ minutes, particularly with systemd version 259 and later.

Problem

• Boot delays: 2+ minutes (up from <30 seconds) during cloud-init local
• Root cause: DNS queries for IP addresses during DNS redirect detection
• Systemd 259 regression: Recent systemd changes make DNS resolution significantly slower during early boot
• Legacy URL: Hardcoded DNS-dependent metadata URL that's no longer documented by AWS

Solution

1. Optimize IP address handling in util.py

• Move IP address detection to function start to bypass all DNS operations
• Remove duplicate IP check that occurred after expensive DNS queries
• IP addresses now completely avoid DNS redirect detection

2. Remove legacy DNS-dependent URL from DataSourceEc2.py

• Remove http://instance-data.:8773 which is not in current AWS IMDS documentation
• Keep only IP-based endpoints that work without DNS resolution

Changes

• cloudinit/util.py: Early return for IP addresses in is_resolvable()
• cloudinit/sources/DataSourceEc2.py: Remove legacy DNS-dependent metadata URL

Testing

• IP addresses return immediately from is_resolvable()
• Cloud-init local completes in <30 seconds (down from 2+ minutes)
• IMDS access works without DNS resolution
• No functional regressions

Related Issues

Fixes #6641 - Systemd version 259 slows down DNS check during cloud-init local

Backward Compatibility

• ✅ No breaking changes
• ✅ Maintains all existing functionality
• ✅ Uses only documented AWS IMDS endpoints

[holmanb]

Thanks for the contribution. Please make sure that you have read the contribution guide.

[holmanb]

The ec2 datasource is used by various other clouds besides just ec2 - and unfortunately not all clouds are known, so this change poses a risk.

[drzee99]

That is confusing. There should be a separate Data Source implementation for each provider. Even if some are same/similar to allow for future changes a cloud provider may implement.

That being said.

It is possible to override the metadata_urls ref: https://cloudinit.readthedocs.io/en/latest/reference/datasources/ec2.html

IMHO the default should be the ones that are provided by the named Data Source (in this case EC2). If this breaks other cloud providers that use the same path, then they should create an config setting for the metadata_url as pr. documentation to add the relevant metadata_urls.

[holmanb]

To be sure that I understand: You are saying that breaking clouds is justified because the code is confusing and there is a workaround that involves manual modifications to the image, right?

[drzee99]

The DataSource is named DataSourceEC2.py - EC2 is explicitly referring to Amazon Web Services EC2 service (in fact "Amazon EC2" is a registered trademark). Thus it should IMHO adhere to what ever is standard for Amazon EC2 at the current point in time.

It is fair that other clouds have implemented similar things, but they should either have their own data sources OR there should be a generic data source (DataSourceGeneric,py). They should not rely on that Amazon EC2 keeps doing things the same way. What if EC2 changes fundamentally "tomorrow"?

This change in DataSourceEC2.py is not important and I'm happy to back it out.

The important change to resolve the issue is that the check for IP addresses is made earlier in is_resolveable() so we do not unnecessarily go into the "Detect DNS Redirection check" when we don't even have a proper network and just try to query the metadata service (the result from this query is used to setup the network).

[drzee99]

I have approved the CLA.

[holmanb]

@drzee99 the CLA check is still failing. Please fix.

[drzee99]

I have tried to revert commit 5ec0eae which was submitted with the wrong email address, which is why CLA check failed. I have then tried to commit it back in this time with the correct user name and email set. I dont know if that fixes the workflow.