Pass the QoS specs directly to the driver in the "create volume" call

Registered by Tzur Eliyahu

Currently, In order to get the QoS specs to the driver, we use cinder.volume.qos_specs module, which has a 'get_qos_specs' function, which talks directly to the database, thus breaking the abstraction, as the driver should not talk directly to the db.

To prevent this, we aim to add the QoS information directly to the type that's associated to the volume that is being passed to the 'create_volume' function.

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
Tzur Eliyahu
Direction:
Needs approval
Assignee:
Tzur Eliyahu
Definition:
Discussion
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

As we see it, we have 3 options:

1. Continue with the way it works right now. which means the driver needs to perform these actions:
 a. get volume_type_id from volume passed to create_volume\retype
 b. get_type_by_id using cinder\volume module (that's the part where the driver talks directly with the db)
 c. get qos_specs_id from type (type is now a dict that was returned from get_type_by_id)
 d. get_qos_specs_by_id (another call to the db, returns a dict of a QoS object)

2. Pass the type info and the QoS info as a parameter inside the volume object.
 Volume is a dict object. volume type and QoS will be a part of the volume object passed down to create_volume, without any talking between db and driver.
 meaning, the 4 steps from earlier will happen in the manager.
 the driver will only need to extract the info from the volume object.
issues: do we need to do this for other driver functions with volume parameter? probably yes. retype is a good example, but maybe not in delete volume.

3. pass the type and QoS as parameters to the function itself. which means we need to change some of the basic functions. Also need to change the API for retype.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.