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 ...).
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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
