On 9/9/2015 1:04 PM, Doug Hellmann wrote:
Excerpts from Sean Dague's message of 2015-09-09 13:36:37 -0400:
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
Right now rootwrap takes as input an oslo.config file, which it reads to
find the filter_path config value, which it interprets as a directory
containing a bunch of other INI files, which it then reads and merges
together into a single set of filters. I'm not sure the symbolic lookup
you're proposing is going to support that use of multiple files. Maybe
it shouldn't?
What about allowing filter_path to contain more than one directory
to scan? That would let projects using os-brick pass their own path and
os-brick's path, if it's different.
Doug
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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
The problem with the static file paths in rootwrap.conf is that we don't
know where those other library filter files are going to end up on the
system when the library is installed. We could hard-code nova's
rootwrap.conf filter_path to include "/etc/os-brick/rootwrap.d" but then
that means the deploy/config management tooling that installing this
stuff needs to copy that directory structure from the os-brick install
location (which we're finding non-deterministic, at least when using
data_files with pbr) to the target location that rootwrap.conf cares about.
That's why we were proposing adding things to rootwrap.conf that
oslo.rootwrap can parse and process dynamically using the resource
access stuff in pkg_resources, so we just say 'I want you to load the
os-brick.filters file from the os-brick project, thanks.'.
--
Thanks,
Matt Riedemann
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
