Re: Cloud metadata over a v6 only link
On Wed, Sep 02, 2020 at 07:55:41PM +0200, Thomas Goirand wrote:
> We discussed it before, and I wasn't sure about the status of $subject
> in OpenStack. However, now I know. After this patch was merged (6 hours
> ago), OpenStack is now capable of providing instance metadata over IPv6:
>
> https://review.opendev.org/#/c/715482/
Neat.
> This means that, in such case, having a v6 only capable image does make
> sense, at least for OpenStack. My take is that, sooner or later, we will
> have the same needs for other clouds, so it'd be nice if we could figure
> out how.
IIRC, cloud-init manages the interface configuration in our openstack,
pretty much entirely based on its defaults. So it's going to take care
of enough early initialization in the local boot stage [1] to access the
metadata endpoints. From there, it'll apply the network configuration
it finds in the datasource (which I guess is the one described at [2]?)
1. https://cloudinit.readthedocs.io/en/latest/topics/boot.html
2. https://specs.openstack.org/openstack/nova-specs/specs/liberty/implemented/metadata-service-network-info.html
If that's accurate, then we might not need to do anything other than
implement (or wait for upstream to implement) cloud-init support for
accessing metadata via the well-known IPv6 link-local address.
Fortunately, this is easier in v6 than in v4, since link-local is a
requirement and local address assignment is built in to the protocol.
> Can someone remind me what was the issue in our image? If I remember
> correctly, cloud-init will wait for DHCP over IPv4 before reading the
> metadata?
That's what it'll do if it determines that it's running in EC2 and needs
to access metadata at 169.254.169.254. I'd guess that, when it gets
support for the OpenStack IPv6 link-local endpoint, it'll try that as
soon as duplicate-address detection completes and it assigns itself a
link-local address. Maybe it'll then fall back to IPv4. Or in theory
it could do a "happy eyeballs" approach, and try both v4 and v6 in
parallel, and use whichever result comes back first.
As was pointed out elsewhere in the thread, OpenStack also provides
config drive support, so presumably that can be used to pass network
configuration without requiring any link-local connectivity. Can that
be used today to provide an IPv6-only network configuration, and do we
handle such a configuration gracefully?
noah
Reply to: