Open Stack

Excerpts from Sean Dague's message of 2015-09-10 14:11:20 -0400:
> 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.

We rely heavily on setuptools, so using that API is probably just as
good. Frankly I don't know the implementation differences. The point is
to use something that exists, though, rather than inventing one, and so
either would satisfy me in that regard.

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

Right, we still need to tell rootwrap what package names to look at, as
Thierry pointed out. So the existing path option probably needs to be
deprecated in favor of a new way of telling the daemon what packages to
consult instead.

Doug

> 
>     -Sean
>