Open Stack

On 09/09/2015 07:16 PM, Doug Hellmann wrote:
> 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:
<snip>
>> 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.

Right now, they are all a bunch of files, they can be anywhere. And then
you have other files that have to reference these files by path, which
can be anywhere. We could just punt in that part and say "punt! every
installer and configuration management install needs to solve this on
their own." I'm not convinced that's a good answer. The os-brick filters
aren't really config. If you change them all that happens is
terribleness. Stuff stops working, and you don't know why. They are data
to exchange with another process about how to function. Honestly, they
should probably be python code that's imported by rootwrap.

Much like the issues around clouds failing when you try to GET /v2 on
the Nova API (because we have a bunch of knobs you have to align for SSL
termination, and a bunch of deployers didn't), I don't think we should
be satisfied with "there's a config for that!" when all that config
means is that someone can break their configuration if they don't get it
exactly right.

	-Sean

-- 
Sean Dague
http://dague.net