Re: Metadata over IPv6

[Brian Haley <[e-mail]>]

On 12/18/19 4:35 AM, [e-mail] wrote:
>>>> Is you problem solvable using "service discovery" (e.g. DNS-SD)?
>>
>> It *might* be, but I can't guarantee DNS will always be present, so it would be better to have a well-known address.  Typically this part of initialization in a cloud image is done in cloud-init, which is right after DHCP completes, and the address it uses is hard-coded in the binary itself to make things simple.
>>
>> That's not to say mDNS couldn't be used, but having to deploy something in order to do a single lookup for 'metadata.local' could add a lot of overhead since there could be thousands of private networks involved, each with it's own daemon.
> 
> We have been around the "service discovery" block a few times. Not one of the industry's proudest moments.
> Not to rehash all the alternatives here.
> 
> If I understand you correctly, the problem you like to solve is "How can I find the Openstack(?) provisioning URL for this link?".

I'd have to ask specifics of the cloud-init maintainers, but from what I 
know and can glean from source code it wants a url:

DEF_MD_URL = "http://169.254.169.254"

This can vary depending on the cloud, and each image for a specific 
cloud will have a "baked-in" url for this.

> I'm little uneasy about reserving a well-known interface-id/address for the purpose. Isn't it a layer violation? I'm just a little concerned about collectivily taking the cost too. And scale as well, if lots of "applications" are required to be provisioned this way.
> 
> There are probably 10-15 ways of doing it.
> If you do DHCP anyway, why couldn't the URL be passed as an option in DHCP?

Yes, there are many ways to do this, it all seems to rely on a 
well-known link-local address being reachable though.  I'm reluctant to 
suggest a DHCP option since it will add complexity since more parts will 
needed to be changed to support it.

-Brian