[openstack-dev] [cinder] [nova] locking concern with os-brick
Matt Riedemann
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 -
>>> 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.
>>
>> 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
>> missed.
>>
>> Anyway, that's my 2 cents.
>>
>> Sean
>>
>>>
>>> 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
>>>
>>> --
>>> Sean Dague
>>> http://dague.net
>>>
>>> __________________________________________________________________________
>>>
>>> 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
>>
>> __________________________________________________________________________
>>
>> 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
>>
>
> I saw the nova one last night:
>
> https://review.openstack.org/#/c/354502/
>
> 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.
--
Thanks,
Matt Riedemann
More information about the OpenStack-dev
mailing list