9337f396ab
This patch is the next step in simplifying how we create and manage Read Only Volume Attachments. Currently, we have multiple ways of doing this including volume_admin_metadata and the connector that's supplied during attachment processes. The problem is that this method requires you to set and match both settings; and there are a lot of places things can go wrong. If you use volume_admin_metadata, the volume must ALWAYS receive a connector that has read only specified in it, otherwise if the values don't match, the attach calls fail. If you don't use the metadata setting (ie you don't want the volume to be exclusively Read Only) you can just specify the mode in the connector. Rather than have these two different settings and juggle the various attachment parameters that have been introduced (attach_mode, access_mode, volume_admin_metadata:read_only...) it would be much more straight forward to just allow the ability to specify an attach mode during attachment-create and use that setting. This change adds that option to attachment-create, but it also keeps backward compatibility with the volume_admin_metadata for those that are using it. Yes, we could just do a version bump and eliminate admin_metadata; but maintaining the two independently is more disruptive than just keeping compatibility. One thing that this change does that might be unexpected, is it eliminates the requirement for volume_admin_metadata and the connectors mode parameters to match. It assumes that if an admin went through the trouble to set a volumes admin_metadata to read only, then it should in fact be read only regardless of the connector. So we always revert to the admin_metadata setting, and modify the connector if they don't match. The next step in getting completely away from admin_metadata is to introduce the ability to create a Read Only volume via types; that will by the global setting for a volume in terms of its attachment setting. None of this enforces anything on the consumer side (the old methods didn't either) but it does set flags on the volume and attachment record indicating what was requested and what we expect the consumer to be doing with the volume. Change-Id: I091f4eb8f1b464bb2dddb0a29245690a0430142e
Team and repository tags
CINDER
You have come across a storage service for an open cloud computing service. It has identified itself as Cinder. It was abstracted from the Nova project.
- Wiki: https://wiki.openstack.org/Cinder
- Developer docs: https://docs.openstack.org/cinder/latest/
- Blueprints: https://blueprints.launchpad.net/cinder
- Release notes: https://docs.openstack.org/releasenotes/cinder/
Getting Started
If you'd like to run from the master branch, you can clone the git repo:
For developer information please see HACKING.rst
You can raise bugs here https://bugs.launchpad.net/cinder
Python client
https://git.openstack.org/cgit/openstack/python-cinderclient