[openstack-dev] [manila]: questions on update-access() changes

Ramana Raja rraja at redhat.com
Mon Jun 20 10:09:35 UTC 2016


On June 18, 2016 1:47:10 AM Ben Swartzlander <ben at swartzlander.org> 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 <rraja at redhat.com> 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 



More information about the OpenStack-dev mailing list