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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
