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
