Search
SupportConsoleDevelopersStart a trialContact

Chapter 9. Adding metadata to instances

download PDF

The Compute (nova) service uses metadata to pass configuration information to instances on launch. The instance can access the metadata by using a config drive or the metadata service.

Config drive
Config drives are special drives that you can attach to an instance when it boots. The config drive is presented to the instance as a read-only drive. The instance can mount this drive and read files from it to get information that is normally available through the metadata service.
Metadata service
The Compute service provides the metadata service as a REST API, which can be used to retrieve data specific to an instance. Instances access this service at 169.254.169.254 or at fe80::a9fe:a9fe.

9.1. Types of instance metadata

Cloud users, cloud administrators, and the Compute service can pass metadata to instances:

Cloud user provided data
Cloud users can specify additional data to use when they launch an instance, such as a shell script that the instance runs on boot. The cloud user can pass data to instances by using the user data feature, and by passing key-value pairs as required properties when creating or updating an instance.
Cloud administrator provided data

The RHOSP administrator uses the vendordata feature to pass data to instances. The Compute service provides the vendordata modules StaticJSON and DynamicJSON to allow administrators to pass metadata to instances:

  • StaticJSON: (Default) Use for metadata that is the same for all instances.
  • DynamicJSON: Use for metadata that is different for each instance. This module makes a request to an external REST service to determine what metadata to add to an instance.

Vendordata configuration is located in one of the following read-only files on the instance:

  • /openstack/{version}/vendor_data.json
  • /openstack/{version}/vendor_data2.json
Compute service provided data
The Compute service uses its internal implementation of the metadata service to pass information to the instance, such as the requested hostname for the instance, and the availability zone the instance is in. This happens by default and requires no configuration by the cloud user or administrator.

9.2. Adding a config drive to all instances

As an administrator, you can configure the Compute service to always create a config drive for instances, and populate the config drive with metadata that is specific to your deployment. For example, you might use a config drive for the following reasons:

  • To pass a networking configuration when your deployment does not use DHCP to assign IP addresses to instances. You can pass the IP address configuration for the instance through the config drive, which the instance can mount and access before you configure the network settings for the instance.
  • To pass data to an instance that is not known to the user starting the instance, for example, a cryptographic token to be used to register the instance with Active Directory post boot.
  • To create a local cached disk read to manage the load of instance requests, which reduces the impact of instances accessing the metadata servers regularly to check in and build facts.

Any instance operating system that is capable of mounting an ISO 9660 or VFAT file system can use the config drive.

Procedure

  1. Open your Compute environment file.

  2. To always attach a config drive when launching an instance, set the following parameter to True: 

    parameter_defaults:
  ComputeExtraConfig:
    nova::compute::force_config_drive: 'true'

  3. Optional: To change the format of the config drive from the default value of iso9660 to vfat, add the config_drive_format parameter to your configuration: 

    parameter_defaults:
  ComputeExtraConfig:
    nova::compute::force_config_drive: 'true'
    nova::compute::config_drive_format: vfat
  4. Save the updates to your Compute environment file.

  5. Add your Compute environment file to the stack with your other environment files and deploy the overcloud: 

    (undercloud)$ openstack overcloud deploy --templates \
 -e [your environment files] \
 -e /home/stack/templates/<compute_environment_file>.yaml \

Verification

  1. Create an instance: 

    (overcloud)$ openstack server create --flavor m1.tiny \
 --image cirros test-config-drive-instance
  2. Log in to the instance.

  3. Mount the config drive:

    • If the instance OS uses udev: 

      # mkdir -p /mnt/config
# mount /dev/disk/by-label/config-2 /mnt/config

    • If the instance OS does not use udev, you need to first identify the block device that corresponds to the config drive: 

      # blkid -t LABEL="config-2" -odevice
/dev/vdb
# mkdir -p /mnt/config
# mount /dev/vdb /mnt/config
  4. Inspect the files in the mounted config drive directory, mnt/config/openstack/{version}/, for your metadata.

9.3. Adding static metadata to instances

You can make static metadata available to all instances in your deployment.

Procedure

  1. Create the JSON file for the metadata.
  2. Open your Compute environment file.

  3. Add the path to the JSON file to your environment file: 

    parameter_defaults:
  ComputeExtraConfig:
    nova::config::nova_config:
      ...
      api/vendordata_jsonfile_path:
        value: <path_to_the_JSON_file>
  4. Save the updates to your Compute environment file.

  5. Add your Compute environment file to the stack with your other environment files and deploy the overcloud: 

    (undercloud)$ openstack overcloud deploy --templates \
 -e [your environment files] \
 -e /home/stack/templates/<compute_environment_file>.yaml \

9.4. Adding dynamic metadata to instances

You can configure your deployment to create instance-specific metadata, and make the metadata available to that instance through a JSON file.

Tip

You can use dynamic metadata on the undercloud to integrate director with a Red Hat Identity Management (IdM) server. An IdM server can be used as a certificate authority and manage the overcloud certificates when SSL/TLS is enabled on the overcloud. For more information, see Add the undercloud to IdM.

Procedure

  1. Open your Compute environment file.

  2. Add DynamicJSON to the vendordata provider module: 

    parameter_defaults:
  ComputeExtraConfig:
    nova::config::nova_config:
      ...
      api/vendordata_providers:
        value: StaticJSON,DynamicJSON

  3. Specify the REST services to contact to generate the metadata. You can specify as many target REST services as required, for example: 

    parameter_defaults:
  ComputeExtraConfig:
    nova::config::nova_config:
      ...
      api/vendordata_providers:
        value: StaticJSON,DynamicJSON
      api/vendordata_dynamic_targets:
        value: target1@http://127.0.0.1:125
      api/vendordata_dynamic_targets:
        value: target2@http://127.0.0.1:126

    The Compute service generates the JSON file, vendordata2.json, to contain the metadata retrieved from the configured target services, and stores it in the config drive directory.

    Note

    Do not use the same name for a target service more than once.

  4. Save the updates to your Compute environment file.

  5. Add your Compute environment file to the stack with your other environment files and deploy the overcloud: 

    (undercloud)$ openstack overcloud deploy --templates \
 -e [your environment files] \
 -e /home/stack/templates/<compute_environment_file>.yaml \
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.