Open Stack

On 8/12/2016 8:54 AM, Matt Riedemann wrote:
> 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.
>

I checked a tempest-dsvm CI run upstream and we don't follow this 
recommendation for our own CI on all changes in OpenStack, so before we 
make this note in the release notes, I'd like to see us use the same 
lock_path for c-vol and n-cpu in devstack for our CI runs.

Also, it should really be a note in the help text of the actual 
lock_path option IMO since it's a latent and persistent thing that 
people are going to need to remember after newton has long been released 
and people deploying OpenStack for the first time AFTER newton shouldn't 
have to know there was a release note telling them not to shoot 
themselves in the foot, it should be in the config option help text.

-- 

Thanks,

Matt Riedemann