Open Stack

On 09/10/2015 01:05 PM, Doug Hellmann wrote:
> Excerpts from Thierry Carrez's message of 2015-09-10 14:23:34 +0200:
>> Sean Dague wrote:
>>> 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.
>>
>> My quick 2cents on this. Rootwrap was designed as a generic solution to
>> wrap privileged calls. That's why filter files are part of its
>> "configuration". The problem is, OpenStack needs a pretty precise set of
>> those filters to be "configured" to run properly. So it's configuration
>> for rootwrap, but not "configuration" for OpenStack.
> 
> That makes them sound like data, not configuration. If that's the case,
> Python's pkgutil module is an existing API for putting a data file
> inside a library and then accessing it. Maybe we should look at moving
> the files to a place that lets us use that, instead of requiring any
> deployer-based configuration at all. Combining that with the "symbolic"
> suggestion from Sean, we would use the package name as the symbol and
> there would be a well-defined resource name within that package to use
> with pkgutil.get_data() [1].
> 
> Doug
> 
> [1] https://docs.python.org/2.7/library/pkgutil.html#pkgutil.get_data

That sounds reasonable as well. Monty and dstuft had sent us down the
get_resource direction instead using setuptools -
https://pythonhosted.org/setuptools/pkg_resources.html. If you think
that get_data is a better option, this would apply just as well there.

The important thing is: filters are tied to code, so should be able to
be looked up symbolicly based on the code level that's installed.

	-Sean

-- 
Sean Dague
http://dague.net