Open Stack

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: OpenStack-dev-request at lists.openstack.org?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