Open Stack

Hi,

There are a few changes that seem to be lined up for Newton to make manila's
share access control, update_access(), workflow better [1] --
reduce races in DB updates, avoid non-atomic state transitions, and
possibly enable the workflow fit in a HA active-active manila
configuration (if not already possible).

The proposed changes ...

a) Switch back to per rule access state (from per share access state) to
   avoid non-atomic state transition.
   
   Understood problem, but no spec or BP yet.


b) Use Tooz [2] (with Zookeeper?) for distributed lock management [3]
   in the access control workflow. 

   Still under investigation and for now fits the share replication workflow [4]. 


c) Allow drivers to update DB models in a restricted manner (only certain
   fields can be updated by a driver API).

   This topic is being actively discussed in the community, and there should be
   a consensus soon on figuring out the right approach, following which there
   might be a BP/spec targeted for Newton. 


Besides these changes, there's a update_access() change that I'd like to revive
(started in Mitaka), storing access keys (auth secrets) generated by a storage
backend when providing share access, i.e.  during update_access(), in the
``share_access_map`` table [5]. This change as you might have figured is a
smaller and a simpler change than the rest, but seems to depend on the approaches
that might be adopted by a) and c).

For now, I'm thinking of allowing a driver's update access()  to return a
dictionary of {access_id: access_key, ...} to (ShareManager)access_helper's
update_access(), which would then update the DB iteratively with access_key
per access_id. Would this approach be valid with changes a) and c) in 
Newton? change a) would make the driver report access status per rule via
the access_helper, during which an 'access_key' can also be returned, 
change c) might allow the driver to directly update the `access_key` in the
DB.

For now, should I proceed with implementing the approach currently outlined
in my spec [5], have the driver's update_access() return a dictionary of 
{access_id: access_key, ...} or wait for approaches for changes a) and c)
to be outlined better?

Thanks,
Ramana

[1] https://etherpad.openstack.org/p/newton-manila-update-access

[2] https://blueprints.launchpad.net/openstack/?searchtext=distributed-locking-with-tooz

[3] https://review.openstack.org/#/c/209661/38/specs/chronicles-of-a-dlm.rst

[4] https://review.openstack.org/#/c/318336/

[5] https://review.openstack.org/#/c/322971/
    http://lists.openstack.org/pipermail/openstack-dev/2015-October/077602.html