cinder/cinder/tests/unit/attachments
John Griffith 9337f396ab Add ability to specify mode to attachment-create
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
2018-07-17 15:50:03 -05:00
..
__init__.py Add new attachment APIS 2017-01-20 11:47:10 -07:00
test_attachments_api.py Add ability to specify mode to attachment-create 2018-07-17 15:50:03 -05:00
test_attachments_manager.py Add ability to specify mode to attachment-create 2018-07-17 15:50:03 -05:00