[Cinder] User visible information in Volume Types

15 Feb 2024

      Hi,

as discussed in the Cinder midcycle meeting: I would like to add 
something to the volume types to be able to see certain information. I 
am also working out a spec for this, but here are the options I have in 
mind/we have discussed yesterday:

Use Cases
--------------

As a non-admin user creating a volume I 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.

Two of those information are:
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, 
that is only accessible for the admin role. 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 other use cases, where an operator wants to set certain 
information about the volume type.

As there are more and more tools that automatically create IaaS 
resources, those information should be accessible in a uniform way.

Possible changes
------------------------

Here are a few ways to solve this problem.

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 getting 
unusable, when some 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.

-----

If you have any other options in mind or want to state your opinion on 
this, please let me know.

greetings
Josephine (Luzi)

Josephine Seifert

simon＠purestorage.com

Josephine Seifert

tags

participants (2)