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
__________________________________________________________________________
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
