[openstack-dev] [cinder] [nova] locking concern with os-brick

Joshua Harlow harlowja at fastmail.com
Sun Aug 14 03:04:13 UTC 2016


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



More information about the OpenStack-dev mailing list