[openstack-dev] [cinder] [nova] os-brick privsep failures and an upgrade strategy?
Daniel P. Berrange
berrange at redhat.com
Tue Jun 14 13:02:54 UTC 2016
On Tue, Jun 14, 2016 at 07:49:54AM -0400, Sean Dague wrote:
> 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
> 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
Any of 3/4/5 work out of the box, but I'm probably favouring
option 4, then 5, then 3.
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
More information about the OpenStack-dev