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 <rr...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
