Sean Dague wrote:
On 07/04/2016 05:36 AM, Sean McGinnis wrote:
On Mon, Jul 04, 2016 at 01:59:09PM +0200, Thierry Carrez wrote:
[...]
The issue here is that oslo.rootwrap uses config files to determine
what to allow, but those are not really configuration files as far
as the application using them is concerned. Those must match the
code being executed.
So from Grenade perspective, those should really not be considered
configuration files, but application files.
[...]
+1
I have to agree with this perspective. They are config files, but they
are a special type of config file that is closely tied in to the code. I
think we should treat them as application files.
I say we allow these changes for grenade and move forward on this. I
think we all agree we want to move to privsep. As long as we document
this very clearly that these changes need to be made for upgrades, I'm
OK with that.
I would really like to be able to decided on this and move forward. I'm
afraid sticking with rootwrap for another cycle with just confuse things
and compound our issues.
So, can we just put them in python code inline then and abandon etc?
Special config files that we don't want anyone to touch, but we put in
/etc, aren't really a thing. You really can't have it both ways. Either
these are in the part of the filesystem where ops expect to change them,
or they are not.
Totally. As I said elsewhere in this thread, most distros are shipping
them under /usr/share/<project>, and oslo.rootwrap by default loads them
from there as well. The only reason it (also) loads filters from
/etc/<something> is that we wanted to let users *add* their own filters
for their own extra plugin code. So I would argue that the right call is
for devstack to deploy them in /usr/share/<project> (where they would
just upgrade in place at the same time the code is updated) ?
Loading them from Python code inline would require more significant
changes (including moving them in all projects, changing rootwrap to
support inline filter loading and a min version bump everywhere...)
--
Thierry Carrez (ttx)
__________________________________________________________________________
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
