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

2016-06-20 Thread Ramana Raja 
On June 18, 2016 1:47:10 AM Ben Swartzlander  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  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

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

2016-06-17 Thread Ben Swartzlander 
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  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

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

2016-06-02 Thread Ramana Raja 
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