Today’s blog post discusses how the OpenStack metadata service works, and it was written by Michael Crane, the OpenStack Lead in VMware’s Global Support Services(GSS).
OpenStack provides a metadata service for cloud instances. This metadata is useful for accessing instance-specific information from within the instance. The primary purpose of this capability is to apply customizations to the instance during boot time if cloud-init or cloudbase-init is configured on your Linux or Windows image, respectively. However, instance metadata can be accessed at any time after the instance boots by the user or by applications running on the instance. In this article, we will describe how the metadata service is implemented in VIO, how to access the metadata from instances, and how to leverage the metadata for in-guest customization.
Metadata Service in VIO
The metadata service is implemented by the nova-api service on each controller node:
Instances can access the metadata via HTTP at the link-local IP address of 169.254.169.254. To manually access the metadata, use curl or wget to make a request and see the content that is available:
#curl http://169.254.169.254/openstack/latest meta_data.json user_data password vendor_data.json
VIO Deployment Details
In VMware Integrated OpenStack, we deploy two NSX Edge Routers, known as metadata proxy routers, in a load-balanced configuration to serve as a proxy for metadata service requests:
Each metadata proxy router is visible to administrative users within OpenStack:
Within OpenStack, an inter-edge network with subnet 169.254.128.0/17 is created and each metadata proxy router is connected to this network:
Routing of Metadata
When an instance accesses the metadata service, the request is routed as follows:
1. An HTTP request to 169.259.169.254 is received by a metadata proxy router
2. The request is forwarded over the inter-edge-net network to metadata proxy edge
3. The request is then sent to the Nova API service to fetch the desired metadata and then to return the metadata to the instance that requested it.
Exploring the Metadata
Within the instance you may want to access the metadata for use in custom scripts. The metadata is provided in JSON format, and it can be accessed with a HTTP GET request to 169.254.169.254:
As an example, if you launched the instance with a key pair, the public key is available via the metadata and can be imported into the instance by a custom script that consumes the metadata API. This is how cloud-init injects the public key to allow SSH login via private key.
Michael Crane is a Solutions Architect with Global Support Services and the Global Technical Lead for VMware Integrated OpenStack. He joined VMware in 2009 as a TSE with the Infrastructure support team (Storage, Fault, Networking). He later became an Escalation Engineer for Storage, SRM, and vSphere Replication and was the Global Technical Lead for SRM.
Pingback: Cloud Metadata Urls, (Wed, Feb 8th) « CyberSafe NV