diff --git a/specs/2024.1/user-visible-information-in-volume-types.rst b/specs/2024.1/user-visible-information-in-volume-types.rst new file mode 100644 index 00000000..44accbb9 --- /dev/null +++ b/specs/2024.1/user-visible-information-in-volume-types.rst @@ -0,0 +1,266 @@ +.. + 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 those information are already +visible for users, when looking into a volume type (e.g. multiattach). Other +information are either not available at all or not visible for non-admin +users. This is a problem when trying to choose a fitting volume type when +creating a volume. + +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. This would also need a whitelist or +blacklist to decide in the API, where to put the information. +The "properties" field of the volume type 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: "properties" 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. +3.d)The policy for the encryption type could be loosend to let users see not +only whether a volume type has an encryption type, but also what algorithm +and provider is used for it. This may have a security impact. + +All the options under 3 are not able to solve the general issue of having a +reliable way to provide user visible information in volume types. Neither will +they solve the problem, that operators are able to add key-value pairs not +meant for scheduling purposes to the volume type extra specs. + + +Data model impact +----------------- + +For 1.a, 3.a and 3.d 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. + +For 3.d there is only one policy check, that is not executed anymore. + +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. + +In case of 3.d this will also expose all information of the encryption type. + + +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 +---------- + +TBD when one of the options is chosen. + + +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 `_ + +* `Discussion in the Cinder Midcycle `_