[openstack-dev] [cinder] [nova] os-brick privsep failures and an upgrade strategy?

Matt Riedemann mriedem at linux.vnet.ibm.com
Tue Jun 14 17:29:11 UTC 2016

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.



Matt Riedemann

More information about the OpenStack-dev mailing list