Open Stack

On 6/14/2016 11:33 AM, Sean Dague wrote:
> On 06/14/2016 09:02 AM, Daniel P. Berrange wrote:
>> On Tue, Jun 14, 2016 at 07:49:54AM -0400, Sean Dague wrote:
>>
>> [snip]
>>
>>> The crux of the problem is that os-brick 1.4 and privsep can't be used
>>> without a config file change during the upgrade. Which violates our
>>> policy, because it breaks rolling upgrades.
>>
>> os-vif support is going to face exactly the same problem. We just followed
>> os-brick's lead by adding a change to devstack to explicitly set the
>> required config options in nova.conf to change privsep to use rootwrap
>> instead of plain sudo.
>>
>> Basically every single user of privsep is likely to face the same
>> problem.
>>
>>> So... we have a few options:
>>>
>>> 1) make an exception here with release notes, because it's the only way
>>> to move forward.
>>
>> That's quite user hostile I think.
>>
>>> 2) have some way for os-brick to use either mode for a transition period
>>> (depending on whether privsep is configured to work)
>>
>> I'm not sure that's viable - at least for os-vif we started from
>> a clean slate to assume use of privsep, so we won't be able to have
>> any optional fallback to non-privsep mode.
>>
>>> 3) Something else.... ?
>>
>> 3) Add an API to oslo.privsep that lets us configure the default
>>    command to launch the helper. Nova would invoke this on startup
>>
>>       privsep.set_default_helper("sudo nova-rootwrap ....")
>>
>> 4) Have oslo.privsep install a sudo rule that grants permission
>>    to run privsep-helper, without needing rootwrap.
>>
>> 5) Have each user of privsep install a sudo rule to grants
>>    permission to run privsep-helper with just their specific
>>    entry point context, without needing rootwrap
>
> 4 & 5 are the same as 1, because python packages don't have standardized
> management of /etc in their infrastructure. The code can't roll forward
> without a config change.
>
> Option #3 is a new one, I wonder if that would get us past here better.
>
> 	-Sean
>

Yeah #3 sounds the best to me, but would need to hear from Angus on this.

-- 

Thanks,

Matt Riedemann