On 2013-12-03 15:56, Sean Dague wrote:
This cinder patch - https://review.openstack.org/#/c/48935/
Is blocked on failing upgrade because the updated oslo lockutils won't
function until there is a specific configuration variable added to the
cinder.conf.
That work around is proposed here -
https://review.openstack.org/#/c/52070/3
However I think this is exactly the kind of forward breaks that we want
to prevent with grenade, as cinder failing to function after a rolling
upgrade because a config item wasn't added is exactly the kind of pain
we are trying to prevent happening to ops.
So the question is, how is this done correctly so that a default can be
set in the cinder code for this value, and it not require a config
change to work?
I don't know that I have a good answer on how to handle this, but for
context this change is the result of a nasty bug in lockutils that meant
external locks were doing nothing if lock_path wasn't set. Basically
it's something we should never have allowed in the first place.
As far as setting this in code, it's important that all of the processes
for a service are using the same value to avoid the same bad situation
we were in before. For tests, we have a lockutils wrapper
(https://github.com/openstack/oslo-incubator/blob/master/openstack/common/lockutils.py#L282) that sets an environment variable to address this, but that only works if all of the processes are going to be spawned from within the same wrapper, and I'm not sure how secure that is for production deployments since it puts all of the lock files in a temporary directory.
-Ben
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
