Just out of curiosity, not 100% related to this thread, but other
applications also bundle configuration files (for example heat templates
@ https://github.com/openstack/magnum/tree/master/magnum/templates)
Should there be some guidelines on how these config files are packaged
and distributed for these projects as well (ie also use pkgutil...);
probably a good idea to have one so that
distributors/installers/packaging folk don't have to do something custom
when packaging these applications/libraries.
-Josh
Thierry Carrez wrote:
Doug Hellmann wrote:
Excerpts from Thierry Carrez's message of 2015-09-10 14:23:34 +0200:
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].
That sounds promising. One trick is that it's the consuming application
that needs to ship the filters, not the library itself (so rootwrap
would have to look into nova resources, not rootwrap resources). Another
trick is that it should require root rights (not nova rights) to change
those resources, otherwise the security model is broken (the whole idea
of rootwrap being to restrict what a compromised nova user can do to the
system).
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
