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
