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