Open Stack

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 
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