add oracle ipv6 single stack imds functionality

[a-dubs]

Proposed Commit Message

N/A

We rebasing 😎

Additional Context

This is to enable future functionality on the Oracle Cloud and will have no immediate ramifications or generally available use cases for the meantime.

Test Steps

These changes were manually tested on both jammy (22.04) and noble (24.04), on Oracle Platform Ubuntu images for testing ipv4 and dual stack, and then on custom built images for ipv6 single stack testing. For this manual validation, the following things were checked:

• No new warnings logged vs unmodified cloud-init package
• No boot speed slowdowns introduced vs unmodified cloud-int package

The new oracle single-stack ipv6 integration tests was run against an existing instance with the following command:

CLOUD_INIT_EXISTING_INSTANCE_ID="ocid1.instance............" \
CLOUD_INIT_PLATFORM="oci" \
CLOUD_INIT_RUN_UNSTABLE="true" \
CLOUD_INIT_KEEP_INSTANCE="true" \
tox -e integration-tests -- \
tests/integration_tests/datasources/test_oracle_ipv6.py

Merge type

• Squash merge using "Proposed Commit Message"
• Rebase and merge unique commits. Requires commit messages per-commit each referencing the pull request number (#<PR_NUM>)

[TheRealFalcon]

This isn't a full review, but I'm commenting on what I think are the big issues to be addressed.

I think you may be trying to make the EphemeralIPNetwork class do more than it needs to. The original purpose of the connectivity url was to see if we could connect to the IMDS BEFORE setting up our ephemeral connection. If we have connectivity due to something outside of cloud-init (i.e., klibc in initramfs on OCI), then cloud-init doesn't need to do the ephemeral network setup. However, you've modified it to attempt to setup the v6 address, and then check for connectivity afterwards. I don't think there's value added by adding the connectivity check after. If we've setup a connection (either ipv4, ipv6, or both), we can assume we have the connectivity we need.

Additionally, the context manager in EphemeralIPNetwork is now attempting to signal to the caller (via ipv6_reached_at_url) if it should be using ipv6 or not. This isn't really the job of EphemeralIPNetwork though, and it's currently preventing v4 from being setup if v6 works, and preventing v6 from being setup if no v6 callback was provided. This is a fairly large change in behavior that would break EC2 as implemented.

I think that the only changes that were needed to ephemeral.py are around allowing adding support for multiple connectivity urls and updating EphemeralIPNetwork to do the connectivity check early in the context manager (see my inline comment for more details).

[TheRealFalcon]

Unused?

[TheRealFalcon]

This isn't gonna work when network_context is util.nullcontext()

[TheRealFalcon]

Is there a reason we need a separate parameter here? Why can't the v6 address be folded into the connectivity_urls_data?

[TheRealFalcon]

Is this comment still relevant?

[TheRealFalcon]

Rather than passing metadata_patterns that is ipv4 or ipv6 specific into this function, I think instead we should set urls here to be all valid metadata urls. We can then add connect_synchronously=False to this wait_for_url call that implements the happy eyeballs algorithm we talked about before. This function will then return the working url that we can use for all future calls.