[openstack-dev] [cinder] [nova] locking concern with os-brick
mriedem at linux.vnet.ibm.com
Fri Aug 12 13:54:46 UTC 2016
On 8/12/2016 8:52 AM, Matt Riedemann wrote:
> On 8/12/2016 8:24 AM, 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 -
>>> 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.
>> And IMO, having the release note is just a CYA step. We can hope someone
>> reads it - and understands it's implications - but it likely will be
>> Anyway, that's my 2 cents.
>>> I've put the devstack patch on a -2 hold until we get ACK from both Nova
>>> and Cinder teams that everyone's cool with this.
>>> Sean Dague
>>> OpenStack Development Mailing List (not for usage questions)
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> OpenStack Development Mailing List (not for usage questions)
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> I saw the nova one last night:
> But I don't know the details, like what are the actual specific things
> that fail w/o this? Vague "trust me, you need to do this or else"
> release notes that impact how people deploy is not fun, so I'd like more
> details before we just put this out there.
This is also probably something that should be advertised on the
openstack-operators ML. I would at least feel more comfortable if this
is a known thing that operators have already been dealing with and we
just didn't realize.
More information about the OpenStack-dev