Open Stack

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.


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