<div style="white-space:pre-wrap">I have enough experience to know that the notes will not be read.<br><br>I think we need to pull Walt and Kendall in and come up with a safer solution to this.<br><br>That is my 2 cents.  :-)<br><br>Jay</div><br><div class="gmail_quote"><div dir="ltr">On Sat, Aug 13, 2016 at 5:07 PM Matt Riedemann <<a href="mailto:mriedem@linux.vnet.ibm.com">mriedem@linux.vnet.ibm.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 8/12/2016 8:54 AM, Matt Riedemann wrote:<br>
> On 8/12/2016 8:52 AM, Matt Riedemann wrote:<br>
>> On 8/12/2016 8:24 AM, Sean McGinnis wrote:<br>
>>> On Fri, Aug 12, 2016 at 05:55:47AM -0400, Sean Dague wrote:<br>
>>>> A devstack patch was pushed earlier this cycle around os-brick -<br>
>>>> <a href="https://review.openstack.org/341744" rel="noreferrer" target="_blank">https://review.openstack.org/341744</a><br>
>>>><br>
>>>> Apparently there are some os-brick operations that are only safe if the<br>
>>>> nova and cinder lock paths are set to be the same thing. Though that<br>
>>>> hasn't yet hit release notes or other documentation yet that I can see.<br>
>>><br>
>>> Patrick East submitted a patch to add a release note on the Cinder side<br>
>>> last night: <a href="https://review.openstack.org/#/c/354501/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/354501/</a><br>
>>><br>
>>>> Is this a thing that everyone is aware of at this point? Are project<br>
>>>> teams ok with this new requirement? Given that lock_path has no<br>
>>>> default,<br>
>>>> this means we're potentially shipping corruption by default to users.<br>
>>>> The other way forward would be to revisit that lock_path by default<br>
>>>> concern, and have a global default. Or have some way that users are<br>
>>>> warned if we think they aren't in a compliant state.<br>
>>><br>
>>> This is a very good point that we are shipping corruption by default. I<br>
>>> would actually be in favor of having a global default. Other than<br>
>>> requiring tooz for default global locking (with a lot of extra overhead<br>
>>> for small deployments), I don't see a better way of making sure the<br>
>>> defaults are safe for those not aware of the issue.<br>
>>><br>
>>> And IMO, having the release note is just a CYA step. We can hope someone<br>
>>> reads it - and understands it's implications - but it likely will be<br>
>>> missed.<br>
>>><br>
>>> Anyway, that's my 2 cents.<br>
>>><br>
>>> Sean<br>
>>><br>
>>>><br>
>>>> I've put the devstack patch on a -2 hold until we get ACK from both<br>
>>>> Nova<br>
>>>> and Cinder teams that everyone's cool with this.<br>
>>>><br>
>>>>     -Sean<br>
>>>><br>
>>>> --<br>
>>>> Sean Dague<br>
>>>> <a href="http://dague.net" rel="noreferrer" target="_blank">http://dague.net</a><br>
>>>><br>
>>>> __________________________________________________________________________<br>
>>>><br>
>>>><br>
>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>> Unsubscribe:<br>
>>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>>> __________________________________________________________________________<br>
>>><br>
>>><br>
>>> OpenStack Development Mailing List (not for usage questions)<br>
>>> Unsubscribe:<br>
>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>><br>
>> I saw the nova one last night:<br>
>><br>
>> <a href="https://review.openstack.org/#/c/354502/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/354502/</a><br>
>><br>
>> But I don't know the details, like what are the actual specific things<br>
>> that fail w/o this? Vague "trust me, you need to do this or else"<br>
>> release notes that impact how people deploy is not fun, so I'd like more<br>
>> details before we just put this out there.<br>
>><br>
><br>
> This is also probably something that should be advertised on the<br>
> openstack-operators ML. I would at least feel more comfortable if this<br>
> is a known thing that operators have already been dealing with and we<br>
> just didn't realize.<br>
><br>
<br>
I checked a tempest-dsvm CI run upstream and we don't follow this<br>
recommendation for our own CI on all changes in OpenStack, so before we<br>
make this note in the release notes, I'd like to see us use the same<br>
lock_path for c-vol and n-cpu in devstack for our CI runs.<br>
<br>
Also, it should really be a note in the help text of the actual<br>
lock_path option IMO since it's a latent and persistent thing that<br>
people are going to need to remember after newton has long been released<br>
and people deploying OpenStack for the first time AFTER newton shouldn't<br>
have to know there was a release note telling them not to shoot<br>
themselves in the foot, it should be in the config option help text.<br>
<br>
--<br>
<br>
Thanks,<br>
<br>
Matt Riedemann<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div>