Merge "Inject metadata properties automatically to non-admin images"
This commit is contained in:
commit
c77664cd77
|
@ -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:
|
||||
<bhagyashri-shewale>
|
||||
|
||||
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
|
||||
|
Loading…
Reference in New Issue