Open Stack

On Sat, Aug 13, 2016 at 08:04:13PM -0700, Joshua Harlow wrote:
> Sean McGinnis wrote:
> >On Fri, Aug 12, 2016 at 05:55:47AM -0400, Sean Dague wrote:
> >>A devstack patch was pushed earlier this cycle around os-brick -
> >>https://review.openstack.org/341744
> >>
> >>Apparently there are some os-brick operations that are only safe if the
> >>nova and cinder lock paths are set to be the same thing. Though that
> >>hasn't yet hit release notes or other documentation yet that I can see.
> >
> >Patrick East submitted a patch to add a release note on the Cinder side
> >last night: https://review.openstack.org/#/c/354501/
> >
> >>Is this a thing that everyone is aware of at this point? Are project
> >>teams ok with this new requirement? Given that lock_path has no default,
> >>this means we're potentially shipping corruption by default to users.
> >>The other way forward would be to revisit that lock_path by default
> >>concern, and have a global default. Or have some way that users are
> >>warned if we think they aren't in a compliant state.
> >
> >This is a very good point that we are shipping corruption by default. I
> >would actually be in favor of having a global default. Other than
> >requiring tooz for default global locking (with a lot of extra overhead
> >for small deployments), I don't see a better way of making sure the
> >defaults are safe for those not aware of the issue.
> 
> What is this 'lot of extra overhead' you might be talking about here?
> 
> You're free when using tooz to pick (or recommend) the backend that
> is the best for the API that you're trying to develop:
> 
> http://docs.openstack.org/developer/tooz/drivers.html
> 
> http://docs.openstack.org/developer/tooz/drivers.html#file is
> similar to the one that oslo.concurrency provides (they both share
> the same underlying lock impl via
> https://pypi.python.org/pypi/fasteners).
> 
> The larger issue here IMHO is that there is now a <between-project>
> API around locking that might be better suited targeting an actual
> lock management system (say redis or zookeeper or etcd or ...).

This is what I'm referring to by overhead. I agree, tooz with the file
driver is very low overhead. But if the projects are still using files
separately in lock_dir/nova and lock_dir/cinder, then it doesn't matter.

What I was (very poorly) trying to point out was this last paragraph.
There would be overhead in requiring zk to be set up to get distrubuted
locking, even for a single node deployment.

So basically, I agree with you completely. ;)

> 
> For example we could have the following lock hierarchy convention:
> 
> openstack/
> ├── cinder
> ├── glance
> ├── neutron
> ├── nova
> └── shared
> 
> The *shared* 'folder' there (not really a folder in some of the
> backends) would be where shared locks (ideally with sub-folders
> defining categories that provide useful context/names describing
> what is being shared) would go, with project-specific locks using
> there respective folders (and so-on).
> 
> Using http://docs.openstack.org/developer/tooz/drivers.html#file u
> could even create the above directory structure as is (right now);
> oslo.concurrency doesn't provide the right ability to do this since
> it has only one configuration option 'lock_path' (and IMHO although
> we could tweak oslo.concurrency more and more to do something like
> that it starts to enter the territory of 'if all you have is a
> hammer, everything looks like a nail').
> 
> That's my 3 cents :-P
> 
> -Josh
> 
> __________________________________________________________________________
> 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