I have enough experience to know that the notes will not be read. I think we need to pull Walt and Kendall in and come up with a safer solution to this.
That is my 2 cents. :-) Jay On Sat, Aug 13, 2016 at 5:07 PM Matt Riedemann <mrie...@linux.vnet.ibm.com> wrote: > 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-requ...@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-requ...@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 > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
