[Openstack] [Quantum] Removing quantum-rootwrap

Dan Wendlandt dan at nicira.com
Wed Aug 8 17:28:37 UTC 2012


On Wed, Aug 8, 2012 at 9:22 AM, Thierry Carrez <thierry at openstack.org>wrote:

> Robert Kukura wrote:
> > On 08/08/2012 09:31 AM, Thierry Carrez wrote:
> >> Quantum currently contains bin/quantum-rootwrap, a copy of nova-rootwrap
> >> supposed to control its privilege escalation to run commands as root.
> >>
> >> However quantum-rootwrap is currently non-functional, missing a lot of
> >> filter definitions that are necessary for it to work correctly.
> >
> > Is missing definitions the only issue? Those may need updating for F-3,
> > but this can certainly be done.
>
> Those are the only issues I spotted. Making Quantum compatible with the
> latest version of rootwrap as shipped in Nova/Cinder, though, is a lot
> more work.
>
> >> Quantum
> >> is generally run with root_helper=sudo and a wildcard sudoers file.
> >
> > What is your basis for this statement? The packaging of Essex Quantum
> > for Fedora and RHEL/EPEL do configure root_helper to use
> > quantum-rootwrap. If another distribution doesn't do this, I would
> > consider that a distribution bug, not an upstream problem.
>
> Given that quantum-rootwrap is currently non-working, I suspected that
> everyone running Quantum *on Folsom* was using sudo and not the
> rootwrap. If most people do that, it probably means it's a it early to
> deprecate root_helper=sudo support in Folsom.
>
> >> That
> >> means Quantum is not ready to deprecate in Folsom (and remove in
> >> Grizzly) its ability to run with root_helper=sudo, like Nova and Cinder
> do.
> >
> > What's involved in deprecating this ability in Folsom? Is it that
> > difficult? If Nova and Cinder are doing it, why shouldn't Quantum?
>
> As a quick grep will show, there is much more adherence to root_helper
> in Quantum than in Nova/Cinder, where it was used in a single place.
> It's definitely doable, but I'd say a bit dangerous (and too late) 4
> days before F3. I certainly won't have enough time for it...
>
> > I do have an issue with Folsom dropping a capability that is being used
> > in Essex. If the existing rootwrap really does more harm than good, this
> > might be justified, but I don't think you can argue nobody has used it.
>
> Fair point, it was definitely used in Essex.
>
> We have three options at this point:
>
> * Remove it (but is it acceptable to "lose" functionality compared to
> Essex, even if Essex is not a "core" release for Quantum ?)
>
> * Just fix it by adding missing filters (but then accept that
> quantum-rootwrap doesn't behave like nova-rootwrap and cinder-rootwrap,
> which is bad for consistency)
>
> * Align quantum-rootwrap with nova-rootwrap and deprecate usage of
> root_helper, by overhauling how root_helper is pervasively used
> throughout Quantum code (lots of work, and introducing a lot of
> disruption that late in the cycle)
>
> Personally I think only the first two options are realistic. So this
> boils down to losing functionality from Essex vs. hurting Folsom core
> consistency.
>

If someone (Bob?) has the immediate cycles to make rootwrap work in Folsom
with low to medium risk of disruption, I'd be open to exploring that, even
if it meant inconsistent usage in quantum vs. nova/cinder.

I also think we need to develop basic guidelines that should be enforced by
reviewers with respect to correctly using rootwrap moving forward.  Is
there a quick pointer we have for developers and reviewers to use?

Dan




>
> --
> Thierry Carrez (ttx)
> Release Manager, OpenStack
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>



-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120808/ca982162/attachment.html>


More information about the Openstack mailing list