Open Stack

We've got a new pattern emerging where some of the key functionality in
services is moving into libraries that can be called from different
services. A good instance of this is os-brick, which has the setup /
config functionality for devices that sometimes need to be called by
cinder and sometimes need to be called by nova when setting up a guest.
Many of these actions need root access, so require rootwrap filters.

The point of putting this logic into a library is that it's self
contained, and that it can be an upgrade unit that is distinct from the
upgrade unit of either nova or cinder.

The problem.... rootwrap.conf. Projects ship an example rootwrap.conf
which specifies filter files like such:

[DEFAULT]
# List of directories to load filter definitions from (separated by ',').
# These directories MUST all be only writeable by root !
filters_path=/etc/nova/rootwrap.d,/usr/share/nova/rootwrap

however, we'd really like to be loading those filters from files the
library controls, so they are in sync with the library functionality.
Knowing where those files are going to be turns out to be a really
interesting guessing game. And, for security reasons, having a super
large set of paths rootwrap is guessing at seems really unwise.

It seems like what we really want is something more like this:

[filters]
nova=compute,network
os-brick=os-brick

Which would translate into a symbolic look up via:

filter_file = resource_filename(project, '%s.filters' % filter)
... read the filter file

So that rootwrap would be referencing things symbolically instead of
static / filebased which is going to be different depending on install
method.


For liberty we just hacked around it and put the os-brick rules into
Nova and Cinder. It's late in the release, and a clear better path
forward wasn't out there. It does mean the upgrade of the two components
is a bit coupled in the fiber channel case. But it was the best we could do.

I'd like to get the discussion rolling about the proposed solution
above. It emerged from #openstack-cinder this morning as we attempted to
get some kind of workable solution and figure out what was next. We
should definitely do a summit session on this one to nail down the
details and the path forward.

	-Sean

-- 
Sean Dague
http://dague.net