Open Stack

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

-- 
Sean Dague
http://dague.net