[openstack-dev] [cinder] [nova] locking concern with os-brick

Sean Dague sean at dague.net
Mon Aug 15 15:05:33 UTC 2016


On 08/14/2016 06:23 PM, Patrick East wrote:
<snip>
> I like the sound of a more unified way to interact with compute node
> services. Having a standardized approach for inter-service
> synchronization for controlling system resources would be sweet (even if
> it is just a more sane way of using local file locks). Anyone know if
> there is existing work in this area we can build off of? Or is the path
> forward a new cross-project spec to try and lock down some requirements,
> use-cases, etc.?
> 
> As far as spending time to hack together solutions via the config
> settings for this.. we'll its pretty minimal wrt size of effort compared
> to solving the large issue. Don't get me wrong though, I'm a fan of
> doing both in parallel. Even if we have resources jump on board
> immediately I'm not convinced we have a great chance to "fix" this for N
> in a more elegant fashion, much less any of the older releases affected
> by this. That leads me to believe we still need the shared config
> setting for at least a little while in Devstack, and documentation for
> existing deployments or ones going up with N.

We were talking through some of the implications of this change in
#openstack-nova, and the following further concerns came out.

1) Unix permissions for services in distros

Both Ubuntu and RHEL have a dedicated service user per service. Nova
services run under nova user, cinder services under cinder. For those
services to share a lock path you need to do more than share the path.

You must also put both services in a group. Make the lockpath group
writable, and ensure all lockfiles get written with g+w permissions
(potentially overriding default system umask to get there).

2) Services in containers

For people pushing towards putting services in containers, you'd need to
do all sorts of additional work to make this lock path actually a shared
construct between 2 containers.


These are both pretty problematic changes for the entire deploy space
without good answers.

	-Sean

-- 
Sean Dague
http://dague.net



More information about the OpenStack-dev mailing list