cloud-init team mailing list archive

[Ryan Harper <ryan.harper@xxxxxxxxxxxxx>]

On Mon, Mar 23, 2020 at 3:41 PM Slawek Kaplonski <skaplons@xxxxxxxxxx>
wrote:

>
> > > > Some initial thoughts and questions:
> > > >
> > > > - In what order should cloud-init try ipv6 and ipv4?
> > > >    - cloud-init would prefer to know which one it should use so we
> don't
> > > timeout on an endpoint that isn't there.
> > >
> > > I would say that it it could be checked what IP addresses are
> configured
> > > in the guest OS already and use correct one if only one type of
> addresses
> > > is there. If there would be both IPv4 and IPv6, it could try IPv4
> first as
> > > it is like that now. What do You think about such solution?
> > >
> >
> > cloud-init runs before networking comes up.  In OpenStack, cloud-init
> will
> > to an Ephemeral DHCP to try to reach metadata service over IPV4.  Once
> > metadata service is crawled, cloud-init will write out network
> > configuration obtained from metadata service.
> > Currently we will try a list of URLs/IPs as configured in the datasource.
> > We can add the IPv6 metadata url to the list, my question is where in the
> > list should it go?  If we put it first, then on deployments which lack
> IPv6
> > metadata service, all VMs will pay a
> > boot speed cost of trying to fetch metadata from a non-existent URL.  If
> > the v6 address is at the end, then IPv6-only deployments will waste time
> > trying to hit an IPv4 url which is not present.  This is why I'm
> interested
> > in being "told" in some way.
>
> But this would still be better than it is now where in IPv6 only
> environment
> cloud-init now is wasting time trying to reach metadata service over IPv4
> and
> finally failing :) So IMO this can be something like first step at least
> (or
> what Bence proposed with new Datasource)
>

Yes; I think we could tackle running the v4 DHCP and ipv6 crawl over
link-local in parallel as a first step.  That should provide the best path
for v4-only and v6-only setups.

Ryan