Excerpts from Matt Riedemann's message of 2015-09-09 13:45:29 -0500: > > 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
I thought the configuration file passed to rootwrap was something the deployer could change, which would let them fix the paths on their system. Did I misunderstand what the argument was? > 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.'. > Doesn't that put the rootwrap config file for os-brick in a place the deployer can't change it? Maybe they're not supposed to? If they're not, then I agree that burying the actual file inside the library and using something like pkgtools to get its contents makes more sense. Doug __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
