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