Open Stack

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 <mriedem at 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-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
>
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160814/fd6517ff/attachment.html>