Spec for user visible information in volume types
Volume types have important aspects, that come in place, when volumes are created. Some of them ar only visible for admins. This spec should discuss options to make more information accessible for users, so they can chose a fitting volume type. Change-Id: Ie2c489829b86dd74605b664af24ce8e1e7aa5d5a Partial-Implements: https://blueprints.launchpad.net/cinder/+spec/user-visible-information-in-volume-types
This commit is contained in:
Josephine Seifert
parent
2a67eec96b
commit
ada8d015fa
|
|
@ -0,0 +1,253 @@
|
|||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
========================================
|
||||
User visible information in volume types
|
||||
========================================
|
||||
|
||||
https://blueprints.launchpad.net/cinder/+spec/user-visible-information-in-volume-types
|
||||
|
||||
Volume types are used to find a fitting backend when creating a volume. But
|
||||
they also imply a few configurations to the volume to be created, that are
|
||||
good to know for anyone who has to choose from various volume types.
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
When a non-admin user is creating a volume they would like to see various
|
||||
information about the volume type. Some of them are already available
|
||||
(e.g. multiattach), while others are either not available at all or not
|
||||
available for non-admin users. This is a problem when trying to choose a
|
||||
fitting volume type.
|
||||
|
||||
Use Cases
|
||||
=========
|
||||
|
||||
The information users would like to see are first and foremost:
|
||||
1. Whether a volume type can be used to create encrypted volumes
|
||||
2. Whether a volume type creates replicated volumes, either through Cinder or
|
||||
through a configured backend like ceph
|
||||
|
||||
The first information comes from the encryption type within the volume, which
|
||||
is only accessible for an admin. The second information can either be set and
|
||||
directly seen in the volume type extra_specs or is indirectly a part of the
|
||||
configuration of the backend.
|
||||
|
||||
There might be more use cases, that should benefit from a solution allowing
|
||||
an admin to add certain user facing information into the volume type in a
|
||||
uniform way.
|
||||
|
||||
As there are more and more tools that automatically create IaaS resources,
|
||||
that information should be accessible in a uniform way and could best be used
|
||||
to filter for fitting volume types in the client.
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
Here are a few ways to solve this problem.
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
1. Using the already existing user facing "properties" field. Administrators
|
||||
can already set key,value pairs here and user visible extra_specs can be
|
||||
seen in this field. This would lead to a problem in the volume scheduler,
|
||||
as EVERY input is going into the extra_specs table and the scheduler will
|
||||
try to fulfill every key=value pair a volume type requests when looking for
|
||||
a fitting backend for the volume.
|
||||
1.a) This could be solved in creating a whitelist or blacklist, so not every
|
||||
extra_spec is checked in the scheduler. Either all only informational
|
||||
extra_specs should be ignored or a list of extra_specs, that will be checked
|
||||
could be created.
|
||||
1.b) Another option would be to create another database table: metadata and
|
||||
put every key=value pair in there at the time of their creation, that should
|
||||
not be used in the scheduling process. The "properties" field would then be
|
||||
build in the API from a merge of the extra_specs and the metadata table.
|
||||
(This may also prevent the volume type from becoming unusable, when someone
|
||||
adds a key=value pair to the "properties", that is not meant for the scheduler
|
||||
- right now this would break the volume creation process)
|
||||
|
||||
2. Creating a new "metadata" field, that will contain such user facing
|
||||
information. This would include API changes to address the new view of the
|
||||
volume type as well as a new API endpoint to set information as key value
|
||||
pairs for this metadata field. A new database table for those metadata is
|
||||
also necessary. The downside on this is, it might confuse people, as user
|
||||
facing information would be in two different fields: "propertied" for
|
||||
multiattach, replication_enabled and AZ, but "metadata" for some things
|
||||
like encryption_enabled and backend_replication, etc... It would also not
|
||||
solve the problem, that key-value pairs not meant for scheduling purposes
|
||||
can still be put into the properties/extra_specs and will only lead to
|
||||
Errors in the scheduling process later on.
|
||||
|
||||
3. Facing use cases individually:
|
||||
3.a) Information about whether a volume type creates encrypted volumes or not
|
||||
could be calculated in the API calls for list/show volume types from the
|
||||
presence of an encryption type. The information would be shown in the
|
||||
"properties" field. This would be a very minimal patch, but will not solve
|
||||
other use cases, that would benefit from user facing information.
|
||||
3.b) Creating an extra field for the encryption in the volume type table, that
|
||||
is automatically set when creating or deleting an encryption type. This
|
||||
would need a database change and a change of the view of the volume_types.
|
||||
3.c) Looking into the different drivers and how they handle internal
|
||||
configurable replication and whether there are ways to let OpenStack know
|
||||
this and propagate it to users. This is very hard to achieve, maybe even
|
||||
impossible without input from an operator, who configured the backends and
|
||||
volume types.
|
||||
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
|
||||
For 1.a and 3.a there are no changes to the data model.
|
||||
|
||||
For 1.b and 2. it would be necessary to create a new table `metadata` that
|
||||
works like the `extra_specs` table. As there are currently no user visible
|
||||
information in volume types in place, an initially empty table would be
|
||||
sufficient.
|
||||
|
||||
For 3.b the volume type table would need to get a new column: `encryption_set`
|
||||
with a boolean option. This could default to false but has to be set to true
|
||||
for every volume type that has an associated encryption type.
|
||||
|
||||
For 3.c it is not yet clear what changes need to be done.
|
||||
|
||||
Additionally for 1.a, 1.b, 2 and 3.b in case of an upgrade from a previous
|
||||
OpenStack version, all volume types need to be checked and for volume types
|
||||
with associated encryption types, there need to be an encryption parameter
|
||||
set in the database according to the chosen option.
|
||||
|
||||
REST API impact
|
||||
---------------
|
||||
|
||||
Each API method which is either added or changed should have the following
|
||||
|
||||
For 1.a and 1.b there would only be minor changes in already existing API
|
||||
calls such as creating a new key-value pair and writing it to the database
|
||||
when creating an encryption type.
|
||||
|
||||
For 1.b and 3.a the list and show calls for the volume type would get an
|
||||
update to mix in either the metadata table or the encryption type into
|
||||
the `properties` field.
|
||||
|
||||
For 3.b there would be an update to the view of the volume type, as an
|
||||
additional field is created and shown.
|
||||
|
||||
For 2 a new field needs to be added to the view of volume types.
|
||||
For that field new API calls will be needed:
|
||||
- a POST method to set new key-value pairs
|
||||
- a DELETE method to delete a key-value pair.
|
||||
These new calls should behave the same way as for the volume type extra specs.
|
||||
|
||||
For 3.c it is not yet clear what changes need to be done.
|
||||
|
||||
In general there should be a clear separation of information being set by
|
||||
admins versus information being set through OpenStack workflows. The latter
|
||||
should not be setable via `openstack volume type set`. Instead a 403 Error
|
||||
should be presented.
|
||||
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
|
||||
This change will expose a boolean value, that shows, whether a volume type
|
||||
will encrypt volumes at creation or not.
|
||||
|
||||
|
||||
Active/Active HA impact
|
||||
-----------------------
|
||||
|
||||
There should not be any impact upon Cinder's Active/Active HA support.
|
||||
|
||||
|
||||
Notifications impact
|
||||
--------------------
|
||||
|
||||
There might be additional notifications when database entries are made or
|
||||
removed. They will behave the same way as the notifications of extra_specs.
|
||||
Those will be sent, whenever an encryption_type is created or deleted and thus
|
||||
a new key-value pair is written into the extra_specs database table or in
|
||||
general when a key-value pair is added to a possible new metadata DB table.
|
||||
|
||||
Other end user impact
|
||||
---------------------
|
||||
|
||||
This change may lead to users wanting to use the filtering mechanism in
|
||||
`openstack volume type list --property key=value` for both explained use
|
||||
cases.
|
||||
|
||||
Performance Impact
|
||||
------------------
|
||||
|
||||
The changes would lead to one additional database call, when creating or
|
||||
deleting an encryption type: then there will also be a key-value pair written
|
||||
to the database either into the `extra_specs` or a potentially new `metadata`
|
||||
table.
|
||||
|
||||
In the case of the creation of a new database table, the API call for getting
|
||||
volume types and their details need to be adjusted or to get an additional
|
||||
query for the new metadata table.
|
||||
|
||||
Other deployer impact
|
||||
---------------------
|
||||
|
||||
Old volume types with associated encryption types will need to have the
|
||||
potentially new database entry set. This cannot be done via `volume type set`
|
||||
command, but has to be written into the database either manually or with a
|
||||
script, that sets the correct entry for all affected volume types.
|
||||
|
||||
Developer impact
|
||||
----------------
|
||||
|
||||
For 1.a this will change the workflow of the cinder scheduler. Developers
|
||||
cannot assume anymore that all entries to the `extra_specs` will be checked
|
||||
in the scheduler.
|
||||
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
Josephine Seifert (josei)
|
||||
|
||||
Other contributors:
|
||||
None
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
Work items or tasks -- break the feature up into the things that need to be
|
||||
done to implement it. Those parts might end up being done by different people,
|
||||
but we're mostly trying to understand the timeline for implementation.
|
||||
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
There are no dependencies.
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
Testing will depend on the chosen option. Some of them will only need unit
|
||||
testing, while others should have at least one tempest test that checks new
|
||||
API endpoints.
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
There might be a documentation needed to separate between the extra specs
|
||||
and the handling of user visible information. It depends on the chosen option.
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
* `Mailing list discussion <https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/PP7IMXVOO2SM47JRMDYYVB2IA3XIEZD5/>`_
|
||||
|
||||
* `Discussion in the Cinder Midcycle <https://etherpad.opendev.org/p/cinder-caracal-midcycles#L93>`_
|
||||
Loading…
Reference in New Issue