https://blueprints.launchpad.net/cinder/+spec/driver-private-data
As discussed at the mid-cycle meetup (https://etherpad.openstack.org/p/cinder- meetup-winter-2015) we want to add a DB table where drivers can store info they need to operate. A specific use case is for iSCSI CHAP credentials for initiators, but it should be generic enough for other drivers to store data they depend on too.
Currently there is not a standard solution for drivers to store information they need to operate. For things volume related we have some “provider” fields on the volume table that can be used, but for things not associated with the volume’s life-cycle they are insufficient. This has lead to some drivers storing information on the backend which works for some but not all backends have this capability.
A use case for this is storing target CHAP secrets so iSCSI initiators can do CHAP authentication against targets.
A solution for this problem is to have a new table in the Cinder database which can hold initiator information for drivers. The model would look like:
+--------------+--------------+--------------------------------------------+
| Field | Type | Description |
+--------------+--------------+--------------------------------------------+
| created_at | datetime | |
| updated_at | datetime | |
| id | int(11) | Auto incremented ID |
| initiator | varchar(255) | Unique constraint with "key" + |
| | | "namespace" |
| namespace | varchar(255) | Unique constraint with "key" + "initiator" |
| | | This comes from cinder.conf for each back |
| | | end configuration. |
| key | varchar(255) | Unique constraint with "initiator" + |
| | | "namespace" |
| value | varchar(255) | This could be anything a driver wants to |
| | | keep track of for this initiator. In the |
| | | CHAP credential usecase this could be a |
| | | barbican key uuid. |
+--------------+--------------+--------------------------------------------+
In initialize_connection for VolumeManager if there is an initiator (in the case of iSCSI) we can look up the rows for it filtering by the namespace and pass them in to the driver as a new optional parameter for initialize_connection.
The namespace field will come from a new configuration option on the driver base class called driver_data_namespace. This config option will default to None. If this option is not set, we will check the backend_name config option, and finally if that is not set, we fall back to the driver class name. This will allow for being able to share data between multiple different backends and a single backend in HA configuration.
The driver then can return a model update dictionary as an “initiator_update” field on the connection info. These changes will then be applied to the initiator table.
The initiator_update dictionary can contain “set_values” dictionary and/or “remove_values” list. The set_values are key value pairs which are to be set or updated in the database. The remove_values is a list of keys to be deleted from the database. They will be “hard” deleted so the data will not remain in the database once specified in remove_values.
The return value from initialize_connection might look somthing like:
{
"driver_volume_type": "iscsi",
"data": {
"target_iqn": "iqn.2010-06.com.purestorage:flasharray.12345abc",
"target_portal": 1.2.3.4:5678,
"target_lun": 1,
"target_discovered": True,
"access_mode": "rw",
"auth_method": "CHAP",
"auth_username": "someUserName",
"auth_password": "somePassword"
},
"initiator_updates":
{
"set_values": {
"purearray1ChapSecretId": "someUUID",
"someOtherThing": "someOtherValue"
}
"remove_values": [
"myOldKey",
"anotherKey"
]
}
}
The manager’s initialize_connection method can then pull the updates out of the return object, do the database operations (as needed) and pass on the connection info with the field stripped out so it does not propagate through the system.
The proposed solution will be adding in a new database table named driver_initiator_data and associated model DriverInitiatorData. There will be a migration to add and remove the table but will not seed or modify any data.
Access to the database will be used through api’s outlined in the Proposed Change.
Table rows will be hard deleted, so we don’t keep around potentially sensitive credentials/information.
None
None
None
None
Potential impact for drivers that heavily utilize this table with extra database queries.
New config option to potentially set for each backend.
Drivers that store data on their backend may want to utilize this feature.
This change will require modifying the signature for all drivers initialize_connection method implementations.
None
None
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.