On June 18, 2016 1:47:10 AM Ben Swartzlander <[email protected]> wrote:
> Ramana, I think your questions got answered in a channel discussion last > week, but I just wanted to double check that you weren't still expecting > any answers here. If you were, please reply and we'll keep this thread going. Thanks, Ben. Are you referring to this discussion, http://eavesdrop.openstack.org/irclogs/%23openstack-manila/%23openstack-manila.2016-06-06.log.html#t2016-06-06T17:15:43, among John, Tom and you? Yes, I followed the above one, and it concluded that I can proceed with my work and need not worry about the approaches of changes a) and c). -Ramana > > > On June 2, 2016 9:30:39 AM Ramana Raja <[email protected]> wrote: > > > 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 > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: [email protected]?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
