From 1549f4a0dceaacffe791019996e66568073c2a62 Mon Sep 17 00:00:00 2001 From: Abhishek Kekane Date: Wed, 13 Sep 2017 03:56:12 +0530 Subject: [PATCH] Inject metadata properties automatically to non-admin images The operator wants user based images to be launched on certain set of compute nodes (host aggregate groups) based on image metadata properties. Change-Id: I6a7ed31d5fae677cbbc9a6f6053f79d3e9326561 Implements: inject-automatic-metadata --- .../glance/inject-automatic-metadata.rst | 211 ++++++++++++++++++ 1 file changed, 211 insertions(+) create mode 100644 specs/queens/approved/glance/inject-automatic-metadata.rst diff --git a/specs/queens/approved/glance/inject-automatic-metadata.rst b/specs/queens/approved/glance/inject-automatic-metadata.rst new file mode 100644 index 00000000..c4a19109 --- /dev/null +++ b/specs/queens/approved/glance/inject-automatic-metadata.rst @@ -0,0 +1,211 @@ +============================================================ +Inject metadata properties automatically to non-admin images +============================================================ + +https://blueprints.launchpad.net/glance/+spec/inject-automatic-metadata + +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. + +Alternatives +------------ + +None + +Data model impact +----------------- + +None + +REST API impact +--------------- + +None + +Security impact +--------------- + +None + +Notifications impact +-------------------- + +None + +Other end user impact +--------------------- + +None + +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 +---------------- + +None + +Implementation +============== + +Assignee(s) +----------- + +Primary assignee: + + +Other contributors: + None + +Reviewers +--------- + +Core reviewer(s): + Erno Kuvaja, Brian Rosmaita + +Other reviewer(s): + None + +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 + +Dependencies +============ + +None + +Testing +======= + +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' + +References +========== + +None +