Inject metadata properties automatically to non-admin images

Inject metadata properties automatically to non-admin images

Cloud operator wants to launch a VM based on certain image metadata properties on different compute nodes.

Problem description

The operator provides public images to the users and users can also add their own images in glance and use these images to launch VMs. As an operator, all images provided by an operator should be launched on a specific set of compute nodes whereas images that are created by non-admin users should be launched on other set of compute nodes. The decision to launch VMs on certain compute nodes will be decided based on image metadata. When an operator will create images, they can specify certain image metadata which will be used by placement api or scheduler service to decide where the vm should be launched but if user creates image, there is no way user will know what image metadata properties to set and hence in the present placement api and scheduler logic, it is possible to launch a VM on any compute nodes. This is a big problem.

Use Case:

The operator wants user based images to be launched on certain set of compute nodes (host aggregate groups) based on image metadata properties.

Proposed change

Make a provision to inject image metadata to non-admin images while adding image to glance backend with the help of property protection. We are planning to introduce two new config options to achieve the same. 1) ‘ignore_user_roles’ is a comma-separated list of roles. Defaults to admin. 2) ‘inject’ defaults to None.

‘inject’ config option will consist of json format (key: value pair) of image metadata which an operator wants to add to the newly created images if user role is not as per mentioned in ‘ignore_user_roles’ config option. If user role is not same as mentioned in ‘ignore_user_roles’ and ‘inject’ doesn’t contain any metadata properties, then no metadata will be injected to the non-admin images.

We propose to create new config file ‘glance-image-import.conf’ which will have all config options related to image import tasks stuff. Each pluggable task can have own section which define its configuration options in this file.

For example, for injecting metadata properties ‘glance-image-import.conf’ will have ‘property_injections’ section described below;

[inject_metadata_properties] ignore_user_roles = admin,… inject = { “property1”: “value”, “property2”: “value,another value” }

Note: When user creates a volume from image, all image metadata will be copied to volume and made available as volume_image_metadata. Now, when user will copy back a volume to image, it will attempt to add ‘property1’ metadata and it will fail as it is only allowed to be created by admin. To address this issue need to make provision like ignore all properties specified in ‘inject’ config option if the request comes from a user whose roles is not specified in ‘ignore_user_roles config option. For example when user performs copy back volume to image then if properties mentioned in inject option will be silently ignored i.e. newly created image from volume does not contains special metadata properties mentioned in ‘inject’ config option.

[some_other_yet_undefined_task] will_have = “it’s own configs”

We will use property protection so that non-admin user won’t be able to add, update or delete the injected metadata properties automatically. Non-admin users however will be able to view these metadata properties. For example if ‘inject’ is set to ‘property1=value’ then in property_protections.conf file, an operator needs to restrict write and delete access for ‘property1’ to non-admin users as described below:

[property1] create = admin read = admin,member,_member_ update = admin delete = admin

In glance, users can create images using two ways. 1) create image API 2) Import image API

In case of import image API, as it uses taskflow, an additional task ‘InjectMetadataProperties’ will be created to inject the metadata. If ‘inject’ property is not None, then only ‘InjectMetadataProperties’ will be part of the tasks, otherwise it will be simply ignored.

No changes will be made to create image API. The intent is that the old upload workflow will only be used by services, it won’t be exposed to end users in most deployments.

Note: There is a restriction on how many image metadata properties an user can set to a image which is configurable using ‘image_property_quota’ config option. If it’s value is 128 and say, if ‘inject’ config option count is 3, then user would be able to add only 125 metadata items by themselves and remaining 3 will be injected automatically. If user tries to add more than 125 metadata items in case of import image api call then the task will marked as failed with appropriate failure message.



Data model impact


REST API impact


Security impact


Notifications impact


Other end user impact


Performance Impact

There is a limit on having additional image metadata properties which defaults to 128. This is configurable using ‘image_property_quota’ option. If an operator sets this limit to higher value and more metadata properties are injected, then it will impact performance during image-list or image-show calls.

This impact is not specifically a result of the proposal in this spec, it’s also the case under the current situation.

Other deployer impact

Administrator need to set ‘ignore_user_roles’ and ‘inject’ config options in ‘inject_metadata_properties’ section of ‘glance-image-import.conf’ config file if metadata properties to be injected for new images for non-admin users.

Developer impact




Primary assignee:
Other contributors:


Core reviewer(s):
Erno Kuvaja, Brian Rosmaita
Other reviewer(s):

Work Items

  • Make provision to read config options from new glance-image-import.conf
  • Add two new config options
  • Add ‘InjectMetadataProperties’ task for import call
  • Add unit tests for coverage
  • Add functional tests




Functional tests will be added to verify that metadata will be injected for non-admin images only.

Documentation Impact

Please refer to ‘Other deployer impact’



Creative Commons Attribution 3.0 License

Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.