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..b1f6e3b0 --- /dev/null +++ b/specs/2024.1/user-visible-information-in-volume-types.rst @@ -0,0 +1,277 @@ +.. + 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. + +* Please do not delete any of the sections in this template. If you have + nothing to say for a whole section, just write: None + +* If your specification proposes any changes to the Cinder REST API such + as changing parameters which can be returned or accepted, or even + the semantics of what happens when a client calls into the API, then + you should add the APIImpact flag to the commit message. Specifications with + the APIImpact flag can be found with the following query: + + https://review.openstack.org/#/q/status:open+project:openstack/cinder-specs+message:apiimpact,n,z + + +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 sould 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, +those 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 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. + + +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 defealt 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 a the 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 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. 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 notification are sent, whenever an encryption_type is created +or deleted adn thus a new kea-value pair is written into the extra_specs +database tbale 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 +--------------------- + +Discuss things that will affect how you deploy and configure OpenStack +that have not already been mentioned, such as: + +There will be no new config options. + +The change will come into effect immediately. + +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 +========== + +Please add any useful references here. You are not required to have any +reference. Moreover, this specification should still make sense when your +references are unavailable. Examples of what you could include are: + +* `Mailing list discussion`_ + +* `Discussion in the Cinde Midcycle`_ \ No newline at end of file