cloud-init team mailing list archive

[Slawek Kaplonski <skaplons@xxxxxxxxxx>]

Hi,

On Mon, Mar 23, 2020 at 09:48:52AM -0500, Ryan Harper wrote:
> On Mon, Mar 16, 2020 at 8:44 AM Slawek Kaplonski <skaplons@xxxxxxxxxx>
> wrote:
> 
> > Hi,
> >
> > > On 11 Mar 2020, at 20:13, Ryan Harper <ryan.harper@xxxxxxxxxxxxx> wrote:
> > >
> > >
> > >
> > > On Wed, Mar 11, 2020 at 4:39 AM Slawek Kaplonski <skaplons@xxxxxxxxxx>
> > wrote:
> > > Hi,
> > >
> > > Hi Slawek,
> > >
> > > Thanks for reaching out to the cloud-init community.
> > >
> > >
> > > I’m OpenStack Neutron developer. Since some time we have proposed spec
> > [1] about Metadata over IPv6 in IPv6 only networks.
> > > This spec proposes to use fe80::a9fe:a9fe IP address as it is equivalent
> > of 169.254.169.254 in IPv6 link-local subnet.
> > >
> > > According to [2] I know already that cloud-init can be configured to use
> > any metadata urls with “metadata_urls” so we can use such IPv6 address (or
> > any other) and can be configured to be used in cloud-init on guest vms.
> > > But as cloud-init is one of the biggest users of Metadata service, I
> > would like to ask cloud-init community what do You think about it and if
> > this will work for You.
> > > Any feedback here or in the spec's review will be appreciated :)
> > >
> > > 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)

> This knowledge would need to come from a non-network area.  Typically this
> is done via DMI tables; however, DMI is not a complete solution as this is
> not available on all architectures (s390x and ppc64le and some arm64),
> which makes this
> sub-optimal.
> 
> 
> > >    -
> > > - cloud-init's EphemeralDHCP code currently relies upon dhclient and
> > ipv4 ips/routes; this will need updating to work with v6; what is needed
> > use fe80::a9fe:a9fe ?
> >
> > As this is link local IP address it should be reachable without any
> > configuration if IPv6 is enabled on the interface in the guest.
> >
> 
> OK.   That makes the v6 support simpler.
> 
> 
> > > - is there a chance that Metadata is available over either v4 or v6?
> > >    - would the data ever diverge?
> >
> > I don’t know if this data can diverge in the future.
> >
> 
> Reading the spec, it appeared to me that the metadata service has no
> changes, rather this was more about configuring which network ports expose
> the service.
> I would not expect there to be a different metadata service on v4 from v6
> (the instance-id is the same either path);
> 
> 
> > >
> > >
> > > Thanks,
> > > Ryan Harper
> > >
> >
> > —
> > Slawek Kaplonski
> > Senior software engineer
> > Red Hat
> >
> >

-- 
Slawek Kaplonski
Senior software engineer
Red Hat