Support temporary Link Local IP for NoCloud metadata similar to cloud providers

[codefritzel]

Enhancement

Enable the NoCloud datasource in cloud-init to reach a metadata server via a Link Local IP address (e.g., 169.254.169.254) in a similar manner to major cloud providers like AWS, OpenStack, or DigitalOcean. This would allow instances using NoCloud to request and consume metadata as other providers' clouds do.

Proposed Implementation

• Introduce a config parameter to activate this feature, ideally settable via DMI (smbios)
• On activation, cloud-init should temporarily assign a Link Local IP address to the interface.
  • Option 1: Use ARP probing to detect available Link Local IP addresses and assign one randomly.
  • Option2: IP allocation via a DHCP server
• The temporary Link Local IP should only be used for metadata access during the early stage of cloud-init.
• After metadata retrieval, release the Link Local IP and continue with the real network configuration.

Motivation

Many clouds use a well-known Link Local IP (e.g., 169.254.169.254) to host a metadata service. I would like to provide VMs (qemu-kvm) with their metadata using the same mechanism. From my point of view, it makes no sense to replicate a cloud provider's metadata service when a standard from cloud-init (nocloud) already exists.

[holmanb]

NoCloud is already capable of getting metadata from a metadata service.

[codefritzel]

Hi @holmanb,
thanks for your answer.

However, cloud-init must have some kind of network configuration in order to access the MetaD, which then has the information about the real network configuration. Data sources such as OpenStack do this via DHCP and a link local address. OpenNebula does it without DHCP and randomly generates a link local address.

Looking at the code, it doesn't seem to me that this is done in NoCloud. Or am I wrong?

[holmanb]

It is documented and it works. Did you try it? I think you have only a partial understanding of the cloud-init behavior in question.