Open Stack

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)