Mailing List Archive: OpenStack: Dev

[Quantum] Removing quantum-rootwrap

1 2

View All

Index | Next | Previous | View Threaded

thierry at openstack

Aug 8, 2012, 6:31 AM

Post #1 of 28 (434 views)
Permalink

[Quantum] Removing quantum-rootwrap

Hi everyone,

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. Quantum
is generally run with root_helper=sudo and a wildcard sudoers file. 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.

I discussed this with Dan, and it appears that the sanest approach would
be to remove quantum-rootwrap from Quantum and only support
root_helper=sudo (the only option that works). I suspect nobody is
actually using quantum-rootwrap right now anyway, given how broken it
seems to be. For the first official release of Quantum as an OpenStack
core project, I would prefer not to ship half-working options :)

Quantum would then wait for rootwrap to move to openstack-common (should
be done in Grizzly) to reconsider using it.

Let me know if any of you see issues with that approach.
(posted to the general list to get the widest feedback).

--
Thierry Carrez (ttx)
Release Manager, OpenStack

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

chuck.short at canonical

Aug 8, 2012, 7:36 AM

Post #2 of 28 (421 views)
Permalink

Re: [Quantum] Removing quantum-rootwrap [In reply to]

Hi,

How much work would would be needed to get this added in quantum?

Thanks
chuck

On Wed, 08 Aug 2012 15:31:59 +0200
Thierry Carrez <thierry [at] openstack> wrote:

> Hi everyone,
>
> 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.
> Quantum is generally run with root_helper=sudo and a wildcard sudoers
> file. 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.
>
> I discussed this with Dan, and it appears that the sanest approach
> would be to remove quantum-rootwrap from Quantum and only support
> root_helper=sudo (the only option that works). I suspect nobody is
> actually using quantum-rootwrap right now anyway, given how broken it
> seems to be. For the first official release of Quantum as an OpenStack
> core project, I would prefer not to ship half-working options :)
>
> Quantum would then wait for rootwrap to move to openstack-common
> (should be done in Grizzly) to reconsider using it.
>
> Let me know if any of you see issues with that approach.
> (posted to the general list to get the widest feedback).
>

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

thierry at openstack

Aug 8, 2012, 7:49 AM

Post #3 of 28 (428 views)
Permalink

Re: [Quantum] Removing quantum-rootwrap [In reply to]

Chuck Short wrote:
> How much work would would be needed to get this added in quantum?

It's actually *in* Quantum right now, it's just not working. It misses
filter definitions, and Quantum code grew some adherence with using
"sudo" directly. So it's a lot of work to fix, a bit late in the cycle
to do that.

And since Quantum is not ready (at all) to deprecate usage of
"root_helper=sudo", the behavior and configuration of a fixed
quantum-rootwrap would differ from nova-rootwrap and cinder-rootwrap,
which would look bad from an integration/doc perspective.

Since I think quantum-rootwrap never actually worked, I prefer to remove
it rather than shipping it broken... Unless someone says it uses it with
great success and can share his magic branch with us :)

--
Thierry Carrez (ttx)
Release Manager, OpenStack

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

rkukura at redhat

Aug 8, 2012, 8:08 AM

Post #4 of 28 (423 views)
Permalink

Re: [Quantum] Removing quantum-rootwrap [In reply to]

On 08/08/2012 09:31 AM, Thierry Carrez wrote:
> Hi everyone,
>
> 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.

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

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

>
> I discussed this with Dan, and it appears that the sanest approach would
> be to remove quantum-rootwrap from Quantum and only support
> root_helper=sudo (the only option that works). I suspect nobody is
> actually using quantum-rootwrap right now anyway, given how broken it
> seems to be. For the first official release of Quantum as an OpenStack
> core project, I would prefer not to ship half-working options :)

The quantum-rootwrap configuration in Essex is being used by anyone who
uses the official Fedora or EPEL RPMs. It may not provide fine-grained
validation of command parameters, but I haven't heard complaints that
its broken. Isn't it better than nothing?

>
> Quantum would then wait for rootwrap to move to openstack-common (should
> be done in Grizzly) to reconsider using it.
>
> Let me know if any of you see issues with that approach.
> (posted to the general list to get the widest feedback).
>

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.

-Bob

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

thierry at openstack

Aug 8, 2012, 9:22 AM

Post #5 of 28 (419 views)
Permalink

Re: [Quantum] Removing quantum-rootwrap [In reply to]

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.

--
Thierry Carrez (ttx)
Release Manager, OpenStack

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

dan at nicira

Aug 8, 2012, 10:28 AM

Post #6 of 28 (420 views)
Permalink

Re: [Quantum] Removing quantum-rootwrap [In reply to]

On Wed, Aug 8, 2012 at 9:22 AM, Thierry Carrez <thierry [at] openstack>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
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~

jrd at redhat

Aug 8, 2012, 1:20 PM

Post #7 of 28 (412 views)
Permalink

Re: [Quantum] Removing quantum-rootwrap [In reply to]

> From: Dan Wendlandt <dan [at] nicira>
> Date: Wed, 8 Aug 2012 10:28:37 -0700
>
> On Wed, Aug 8, 2012 at 9:22 AM, Thierry Carrez <thierry [at] openstack> 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. �
>

Hi Dan. I've been working with Bob, getting myself up to speed on
quantum. I've just talked it over with Bob, and I'll take a crack at
this one. My approach is going to be to get the quantum rootwrap
stuff up to parity with nova. It sounded like some further work might
get done in this area for Grizzly, but for the short term, this ought
to be fairly non-disruptive.

> 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
> Unsubscribe : https://launchpad.net/~openstack
> More help � : https://help.launchpad.net/ListHelp
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt�
> Nicira, Inc:�www.nicira.com
> twitter: danwendlandt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> ----------------------------------------------------------------------
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

dan at nicira

Aug 8, 2012, 3:53 PM

Post #8 of 28 (409 views)
Permalink

Re: [Quantum] Removing quantum-rootwrap [In reply to]

On Wed, Aug 8, 2012 at 1:20 PM, <jrd [at] redhat> wrote:
>
> >
> > 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.
> >
>
> Hi Dan. I've been working with Bob, getting myself up to speed on
> quantum. I've just talked it over with Bob, and I'll take a crack at
> this one. My approach is going to be to get the quantum rootwrap
> stuff up to parity with nova. It sounded like some further work might
> get done in this area for Grizzly, but for the short term, this ought
> to be fairly non-disruptive.
>

Nice to meet you, glad you'll be helping here. Let's stay in close sync
about this change, as I'd like to get a better understanding of how
disruptive/risky this is change is if we're thinking of putting it in
Folsom.

Dan

>
> > 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
> > Unsubscribe : https://launchpad.net/~openstack
> > More help : https://help.launchpad.net/ListHelp
> >
> > --
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Dan Wendlandt
> > Nicira, Inc: www.nicira.com
> > twitter: danwendlandt
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> >
> > ----------------------------------------------------------------------
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack
> > Post to : openstack [at] lists
> > Unsubscribe : https://launchpad.net/~openstack
> > More help : https://help.launchpad.net/ListHelp
> >
>

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~

thierry at openstack

Aug 9, 2012, 1:34 AM

Post #9 of 28 (415 views)
Permalink

Re: [Quantum] Removing quantum-rootwrap [In reply to]

jrd [at] redhat wrote:
>> From: Dan Wendlandt <dan [at] nicira>
>> 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.
>
> Hi Dan. I've been working with Bob, getting myself up to speed on
> quantum. I've just talked it over with Bob, and I'll take a crack at
> this one. My approach is going to be to get the quantum rootwrap
> stuff up to parity with nova. It sounded like some further work might
> get done in this area for Grizzly, but for the short term, this ought
> to be fairly non-disruptive.

There are a number of changes:

* Switch to configuration-based filters
This should be relatively straightforward, although Quantum makes use of
root_helper in *many* more places than Nova/Cinder do. You can have a
look at:
https://github.com/openstack/cinder/commit/d2d3c9cba4a647724f75c036a1985a10c966da35

* Switch to rootwrap_config and deprecate root_helper
This would fully align quantum-rootwrap with nova-rootwrap. However I'm
not sure it's reasonable to deprecate root_helper=sudo in Folsom, given
how little tested quantum-rootwrap seems to be on Folsom. Maybe just
introducing rootwrap_config but leaving the deprecation message out ?
You can have a look at:
https://github.com/openstack/cinder/commit/2b2c97eb5ca332ce7d1f83e4fd2e81fabe0acb66

* Add missing filters, fix incomplete ones
You have to audit all uses of root_helper and add the corresponding
filter. In some cases the filter is there but the parameters are wrong
(kill, missing -HUP as an allowed signal). I also spotted one call that
sets environment before calling root_helper: that needs to use a
specific filter since rootwrap filters the environment out (see how
DnsmasqFilter works).

* Testing
The fact that nobody filed bugs around quantum-rootwrap being unusable
tends to show nobody actually uses Quantum with it (hence my suggestion
to remove it). If we are to ship that option, it needs to be tested one
way or another.

I don't think it would be that disruptive (given that quantum-rootwrap
doesn't really work right now anyway). It is, however, a significant
amount of work to complete before the F3 cut Tuesday at end of day.
Corner-case missing filters can be treated as bugs post-F3 though.

I'm available to help you and answer any question on the design of the
rootwrap you may have.

--
Thierry Carrez (ttx)
Release Manager, OpenStack

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

jrd at redhat

Aug 9, 2012, 6:16 AM

Post #10 of 28 (411 views)
Permalink

Re: [Quantum] Removing quantum-rootwrap [In reply to]

> From: Thierry Carrez <thierry [at] openstack>
> Date: Thu, 09 Aug 2012 10:34:17 +0200
>
> jrd [at] redhat wrote:
> >> From: Dan Wendlandt <dan [at] nicira>
> >> 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.
> >
> > Hi Dan. I've been working with Bob, getting myself up to speed on
> > quantum. I've just talked it over with Bob, and I'll take a crack at
> > this one. My approach is going to be to get the quantum rootwrap
> > stuff up to parity with nova. It sounded like some further work might
> > get done in this area for Grizzly, but for the short term, this ought
> > to be fairly non-disruptive.
>
> There are a number of changes:
>
> * Switch to configuration-based filters
> This should be relatively straightforward, although Quantum makes use of
> root_helper in *many* more places than Nova/Cinder do. You can have a
> look at:
> https://github.com/openstack/cinder/commit/d2d3c9cba4a647724f75c036a1985a10c966da35

Yes, I believe that's one of the changesets I've already been looking
at. Glad to know I'm not off in the weeds :-)

>
> * Switch to rootwrap_config and deprecate root_helper
> This would fully align quantum-rootwrap with nova-rootwrap. However I'm
> not sure it's reasonable to deprecate root_helper=sudo in Folsom, given
> how little tested quantum-rootwrap seems to be on Folsom. Maybe just
> introducing rootwrap_config but leaving the deprecation message out ?
> You can have a look at:
> https://github.com/openstack/cinder/commit/2b2c97eb5ca332ce7d1f83e4fd2e81fabe0acb66
>

Ok. I did talk through this issue with Bob yesterday, but I'd be
lying if I said I understood it all yet.

Let me ask this: Since, as you say, there's not a lot of evidence of
traffic through quantum-rootwrap, is there an obvious downside to
deprecating root_helper=sudo at this stage? I'm not advocating either
way, just trying to get up to speed on all the parts of the issue.

> * Add missing filters, fix incomplete ones
> You have to audit all uses of root_helper and add the corresponding
> filter. In some cases the filter is there but the parameters are wrong
> (kill, missing -HUP as an allowed signal). I also spotted one call that
> sets environment before calling root_helper: that needs to use a
> specific filter since rootwrap filters the environment out (see how
> DnsmasqFilter works).
>

Ok. I haven't seen those, or didn't know what I was looking at, but
I'll keep attention out for that stuff.

> * Testing
> The fact that nobody filed bugs around quantum-rootwrap being unusable
> tends to show nobody actually uses Quantum with it (hence my suggestion
> to remove it). If we are to ship that option, it needs to be tested one
> way or another.

Yes. Honestly, this is the part which I feel most unsure about. But
I've decided to try to get my head around the code first, and then
understand the testing implications. I will doubtless have more
questions about that.

>
> I don't think it would be that disruptive (given that quantum-rootwrap
> doesn't really work right now anyway). It is, however, a significant
> amount of work to complete before the F3 cut Tuesday at end of day.
> Corner-case missing filters can be treated as bugs post-F3 though.
>

Ok, understood.

My goal is by end of today , or tomorrow morning latest, to have at
least a reasonably complete understanding of the changes necessary to
get the quantum-rootwrap facility up to parity with nova/cinder. If I
get to that deadline and I'm not there, I'll probably punt, as it
becomes too much of a hail-mary to get the stuff stabilized and
reviewed etc by tues.

> I'm available to help you and answer any question on the design of the
> rootwrap you may have.

Thanks very much. I will certainly have more questions as I proceed.

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

thierry at openstack

Aug 9, 2012, 7:32 AM

Post #11 of 28 (408 views)
Permalink

Re: [Quantum] Removing quantum-rootwrap [In reply to]

jrd [at] redhat wrote:
>> * Switch to rootwrap_config and deprecate root_helper
>> This would fully align quantum-rootwrap with nova-rootwrap. However I'm
>> not sure it's reasonable to deprecate root_helper=sudo in Folsom, given
>> how little tested quantum-rootwrap seems to be on Folsom. Maybe just
>> introducing rootwrap_config but leaving the deprecation message out ?
>> You can have a look at:
>> https://github.com/openstack/cinder/commit/2b2c97eb5ca332ce7d1f83e4fd2e81fabe0acb66
>>
>
> Ok. I did talk through this issue with Bob yesterday, but I'd be
> lying if I said I understood it all yet.
>
> Let me ask this: Since, as you say, there's not a lot of evidence of
> traffic through quantum-rootwrap, is there an obvious downside to
> deprecating root_helper=sudo at this stage? I'm not advocating either
> way, just trying to get up to speed on all the parts of the issue.

Well, since there is not a lot of evidence of traffic through the
rootwrap, that means almost everyone is using root_helper=sudo. Marking
it deprecated, and recommending that everyone switches to the (untested
yet) rootwrap doesn't sound that much like a great idea.

I think we should deprecate root_helper=sudo when we are confident that
most people are using rootwrap and are satisfied with it.

> My goal is by end of today , or tomorrow morning latest, to have at
> least a reasonably complete understanding of the changes necessary to
> get the quantum-rootwrap facility up to parity with nova/cinder. If I
> get to that deadline and I'm not there, I'll probably punt, as it
> becomes too much of a hail-mary to get the stuff stabilized and
> reviewed etc by tues.

That sounds reasonable.

--
Thierry Carrez (ttx)
Release Manager, OpenStack

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

jrd at redhat

Aug 9, 2012, 7:42 AM

Post #12 of 28 (411 views)
Permalink

Re: [Quantum] Removing quantum-rootwrap [In reply to]

> From: Thierry Carrez <thierry [at] openstack>
> Date: Thu, 09 Aug 2012 16:32:23 +0200
>
> jrd [at] redhat wrote:
> >> * Switch to rootwrap_config and deprecate root_helper
> >> This would fully align quantum-rootwrap with nova-rootwrap. However I'm
> >> not sure it's reasonable to deprecate root_helper=sudo in Folsom, given
> >> how little tested quantum-rootwrap seems to be on Folsom. Maybe just
> >> introducing rootwrap_config but leaving the deprecation message out ?
> >> You can have a look at:
> >> https://github.com/openstack/cinder/commit/2b2c97eb5ca332ce7d1f83e4fd2e81fabe0acb66
> >>
> >
> > Ok. I did talk through this issue with Bob yesterday, but I'd be
> > lying if I said I understood it all yet.
> >
> > Let me ask this: Since, as you say, there's not a lot of evidence of
> > traffic through quantum-rootwrap, is there an obvious downside to
> > deprecating root_helper=sudo at this stage? I'm not advocating either
> > way, just trying to get up to speed on all the parts of the issue.
>
> Well, since there is not a lot of evidence of traffic through the
> rootwrap, that means almost everyone is using root_helper=sudo. Marking
> it deprecated, and recommending that everyone switches to the (untested
> yet) rootwrap doesn't sound that much like a great idea.
>

Ah. Ok, got it.

> I think we should deprecate root_helper=sudo when we are confident that
> most people are using rootwrap and are satisfied with it.
>

Yes, concur.

Thanks. Onward...

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

rkukura at redhat

Aug 9, 2012, 8:13 AM

Post #13 of 28 (414 views)
Permalink

Re: [Quantum] Removing quantum-rootwrap [In reply to]

On 08/09/2012 10:32 AM, Thierry Carrez wrote:
> jrd [at] redhat wrote:
>>> * Switch to rootwrap_config and deprecate root_helper
>>> This would fully align quantum-rootwrap with nova-rootwrap. However I'm
>>> not sure it's reasonable to deprecate root_helper=sudo in Folsom, given
>>> how little tested quantum-rootwrap seems to be on Folsom. Maybe just
>>> introducing rootwrap_config but leaving the deprecation message out ?
>>> You can have a look at:
>>> https://github.com/openstack/cinder/commit/2b2c97eb5ca332ce7d1f83e4fd2e81fabe0acb66
>>>
>>
>> Ok. I did talk through this issue with Bob yesterday, but I'd be
>> lying if I said I understood it all yet.
>>
>> Let me ask this: Since, as you say, there's not a lot of evidence of
>> traffic through quantum-rootwrap, is there an obvious downside to
>> deprecating root_helper=sudo at this stage? I'm not advocating either
>> way, just trying to get up to speed on all the parts of the issue.
>
> Well, since there is not a lot of evidence of traffic through the
> rootwrap, that means almost everyone is using root_helper=sudo. Marking
> it deprecated, and recommending that everyone switches to the (untested
> yet) rootwrap doesn't sound that much like a great idea.
>
> I think we should deprecate root_helper=sudo when we are confident that
> most people are using rootwrap and are satisfied with it.

By "almost everyone" and "most people", do you mean users of devstack?
I'd hate to think people are trying to deploy the quantum Folsom master
branch with all the change that's been going on.

We should immediately change devstack to stop running the quantum agents
as root, so at least the root_helper=sudo functionality is really being
used.

It looks like devstack does configure nova with the new
rootwrap/rootwrap_config and does not run any of its services as root.
Doing the same for quantum would seem get some mileage on it.

What exactly is involved in deprecating root_helper=sudo? Is this
something we could chose whether or not to do at the last minute after
implementing the new rootwrap and changing devstack to use it?

Thanks,

-Bob

>
>> My goal is by end of today , or tomorrow morning latest, to have at
>> least a reasonably complete understanding of the changes necessary to
>> get the quantum-rootwrap facility up to parity with nova/cinder. If I
>> get to that deadline and I'm not there, I'll probably punt, as it
>> becomes too much of a hail-mary to get the stuff stabilized and
>> reviewed etc by tues.
>
> That sounds reasonable.
>

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

vishvananda at gmail

Aug 9, 2012, 10:29 AM

Post #14 of 28 (410 views)
Permalink

Re: [Quantum] Removing quantum-rootwrap [In reply to]

On Aug 9, 2012, at 8:13 AM, Robert Kukura <rkukura [at] redhat> wrote:

> We should immediately change devstack to stop running the quantum agents
> as root, so at least the root_helper=sudo functionality is really being
> used.
>
> It looks like devstack does configure nova with the new
> rootwrap/rootwrap_config and does not run any of its services as root.
> Doing the same for quantum would seem get some mileage on it.

+1

Getting quantum into the devstack-gate would also make sure that we don't
break it in the future.

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

thierry at openstack

Aug 10, 2012, 3:25 AM

Post #15 of 28 (412 views)
Permalink

Re: [Quantum] Removing quantum-rootwrap [In reply to]

Robert Kukura wrote:
> On 08/09/2012 10:32 AM, Thierry Carrez wrote:
>>> Let me ask this: Since, as you say, there's not a lot of evidence of
>>> traffic through quantum-rootwrap, is there an obvious downside to
>>> deprecating root_helper=sudo at this stage? I'm not advocating either
>>> way, just trying to get up to speed on all the parts of the issue.
>>
>> Well, since there is not a lot of evidence of traffic through the
>> rootwrap, that means almost everyone is using root_helper=sudo. Marking
>> it deprecated, and recommending that everyone switches to the (untested
>> yet) rootwrap doesn't sound that much like a great idea.
>>
>> I think we should deprecate root_helper=sudo when we are confident that
>> most people are using rootwrap and are satisfied with it.
>
> By "almost everyone" and "most people", do you mean users of devstack?
> I'd hate to think people are trying to deploy the quantum Folsom master
> branch with all the change that's been going on.

Well, I'm sure Folsom testers are not using quantum-rootwrap, since it
currently doesn't work. The only other option being (the default)
root_helper=sudo, I maintain that "almost everyone" testing Folsom run
root_helper=sudo. That may mean that "most people" testing Folsom run
devstack :)

> We should immediately change devstack to stop running the quantum agents
> as root, so at least the root_helper=sudo functionality is really being
> used.

That's the very minimum. I thought that was the case already...

> It looks like devstack does configure nova with the new
> rootwrap/rootwrap_config and does not run any of its services as root.
> Doing the same for quantum would seem get some mileage on it.

Agreed. That cannot be done until quantum-rootwrap is fixed, though.

> What exactly is involved in deprecating root_helper=sudo? Is this
> something we could chose whether or not to do at the last minute after
> implementing the new rootwrap and changing devstack to use it?

Yes, adding the warning about a deprecated option can be done at the
last minute after implementing the new rootwrap. We are still very much
supporting the old option for the next release, so it's not destructive
at all. The question is rather if we trust the quantum-rootwrap enough
to actively encourage people to migrate to it during Folsom life.

Nova-rootwrap has seen wide adoption by all distros (and devstack) over
the Essex timeframe, it's now used in almost all deployments, so we can
easily warn about root_helper=sudo being deprecated in Nova/Cinder in
Folsom.

I thought quantum-rootwrap was in the same situation, but it's not even
working, two days away from FeatureFreeze. We may be able to fix it
(rather than having to remove it), but I don't think we can assume that
it's the thing most people use... so it may not be mature enough for us
to mark the other option deprecated.

--
Thierry Carrez (ttx)
Release Manager, OpenStack

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

jrd at redhat

Aug 10, 2012, 7:49 AM

Post #16 of 28 (407 views)
Permalink

Re: [Quantum] Removing quantum-rootwrap [In reply to]

> From: Thierry Carrez <thierry [at] openstack>
> Date: Thu, 09 Aug 2012 16:32:23 +0200
>
[...]
>
> > My goal is by end of today , or tomorrow morning latest, to have at
> > least a reasonably complete understanding of the changes necessary to
> > get the quantum-rootwrap facility up to parity with nova/cinder. If I
> > get to that deadline and I'm not there, I'll probably punt, as it
> > becomes too much of a hail-mary to get the stuff stabilized and
> > reviewed etc by tues.
>
> That sounds reasonable.
>

Ok, here's what I think I know, and what I propose to do with it:

Fix quantum/bin/quantum-rootwrap to mimic changes to nova/cinder w/r/t
conf file. This will introduce the notion of
/etc/quantum/rootwrap.conf and allow for specifying path to filter specs.

Fix quantum/rootwrap/filters.py likewise; update KillFilter (maybe more?)

Fix quantum/rootwrap/wrapper.py likewise; load from files and
construct filter datastructures

Create etc/quantum/quantum-rootwrap.conf etc/quantum/rootwrap.d/

Move the filter specs from the various agent pieces in
quantum/rootwrap to matching files in etc/quantum/filters.d. Update
them while I'm at it. This probably means that those files in
quantum/rootwrap go away. Alternate implementation: Collect all
those pieces into a consolidated quantum.filters file and stick that
in there.

There appears to be no analog of nova/tests/test_nova_rootwrap.py for
quantum, so I'll likely need to write something for that.

It looks like the various .ini files in etc/quantum/plugins all set
root helper for each agent. Keep that structure for now, revisit
later. That likely means I'll need a way to propagate the a default
root helper setting from the conf to each agent.

Devstack appears to frob configs in nova and cinder, but copy the
quantum configs verbatim. So I'm hoping I can get away without
modifying devstack.

Things I don't know yet:

Python compatibility? I'm running 2.7; I don't believe anything I'm
doing would break in earlier ones, but I gather that that will need to
be tested before I'm done.

Will I need to hair up the filter match code? I don't think so, but I
haven't gotten enough working yet to tell. Hoping I can leave it as
is.

Apologies for the not-very coherent description. Please let me know
if you think I'm off in the weeds or missing important bits.

Thanks in advance...

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

thierry at openstack

Aug 10, 2012, 8:38 AM

Post #17 of 28 (400 views)
Permalink

Re: [Quantum] Removing quantum-rootwrap [In reply to]

jrd [at] redhat wrote:
> Apologies for the not-very coherent description. Please let me know
> if you think I'm off in the weeds or missing important bits.

One other thing I spotted when I evaluated how broken quantum-rootwrap
was is at quantum/agent/linux/dhcp.py:181 where a command is called with
environment set. That works with sudo but rootwrap clears the
environment. This call therefore needs a specific filter (and probably
never worked with rootwrap).

There is one filter defined for dnsmasq (the DnsmasqFilter which is
defined at quantum/rootwrap/filters.py:71) but it sets a slightly
different set of env variables. So it might need to be adapted (or the
call adjusted).

Hope this helps.

--
Thierry Carrez (ttx)
Release Manager, OpenStack

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

jrd at redhat

Aug 10, 2012, 8:52 AM

Post #18 of 28 (407 views)
Permalink

Re: [Quantum] Removing quantum-rootwrap [In reply to]

> From: Thierry Carrez <thierry [at] openstack>
> Date: Fri, 10 Aug 2012 17:38:52 +0200
>
> jrd [at] redhat wrote:
> > Apologies for the not-very coherent description. Please let me know
> > if you think I'm off in the weeds or missing important bits.
>
> One other thing I spotted when I evaluated how broken quantum-rootwrap
> was is at quantum/agent/linux/dhcp.py:181 where a command is called with
> environment set. That works with sudo but rootwrap clears the
> environment. This call therefore needs a specific filter (and probably
> never worked with rootwrap).

Hmmm. I hadn't even considered that. Ok, I'll keep that in mind as
I'm in there.

>
> There is one filter defined for dnsmasq (the DnsmasqFilter which is
> defined at quantum/rootwrap/filters.py:71) but it sets a slightly
> different set of env variables. So it might need to be adapted (or the
> call adjusted).
>
Fair enough. I don't even know what that does yet, so will need to
work that out and figure out how to adjust.

> Hope this helps.

Very much, thanks. More news as it happens...

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

patnala003 at gmail

Aug 12, 2012, 10:42 PM

Post #19 of 28 (382 views)
Permalink

Re: [Quantum] Removing quantum-rootwrap [In reply to]

Hello Thierry,

Can we download Folsom branch codebase for understanding Quantum and other
changes in Folsom release?

Please give us your comments,experience and known issues.

Thanks in advance.

-balaji

On Wed, Aug 8, 2012 at 7:01 PM, Thierry Carrez <thierry [at] openstack>wrote:

> Hi everyone,
>
> 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. Quantum
> is generally run with root_helper=sudo and a wildcard sudoers file. 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.
>
> I discussed this with Dan, and it appears that the sanest approach would
> be to remove quantum-rootwrap from Quantum and only support
> root_helper=sudo (the only option that works). I suspect nobody is
> actually using quantum-rootwrap right now anyway, given how broken it
> seems to be. For the first official release of Quantum as an OpenStack
> core project, I would prefer not to ship half-working options :)
>
> Quantum would then wait for rootwrap to move to openstack-common (should
> be done in Grizzly) to reconsider using it.
>
> Let me know if any of you see issues with that approach.
> (posted to the general list to get the widest feedback).
>
> --
> Thierry Carrez (ttx)
> Release Manager, OpenStack
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>

gkotton at redhat

Aug 12, 2012, 11:19 PM

Post #20 of 28 (381 views)
Permalink

Re: [Quantum] Removing quantum-rootwrap [In reply to]

On 08/13/2012 08:42 AM, balaji patnala wrote:
> Hello Thierry,
>
> Can we download Folsom branch codebase for understanding Quantum and
> other changes in Folsom release?

You can get the code at git://github.com/openstack/quantum.git.
If you would like to see the status of things regarding F-3 then please
look at https://launchpad.net/quantum/.

The guys in the community have done some great work over the last few weeks!

> Please give us your comments,experience and known issues.
>
> Thanks in advance.
>
> -balaji
>
> On Wed, Aug 8, 2012 at 7:01 PM, Thierry Carrez <thierry [at] openstack
> <mailto:thierry [at] openstack>> wrote:
>
> Hi everyone,
>
> 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.
> Quantum
> is generally run with root_helper=sudo and a wildcard sudoers
> file. 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.
>
> I discussed this with Dan, and it appears that the sanest approach
> would
> be to remove quantum-rootwrap from Quantum and only support
> root_helper=sudo (the only option that works). I suspect nobody is
> actually using quantum-rootwrap right now anyway, given how broken it
> seems to be. For the first official release of Quantum as an OpenStack
> core project, I would prefer not to ship half-working options :)
>
> Quantum would then wait for rootwrap to move to openstack-common
> (should
> be done in Grizzly) to reconsider using it.
>
> Let me know if any of you see issues with that approach.
> (posted to the general list to get the widest feedback).
>
> --
> Thierry Carrez (ttx)
> Release Manager, OpenStack
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> <https://launchpad.net/%7Eopenstack>
> Post to : openstack [at] lists
> <mailto:openstack [at] lists>
> Unsubscribe : https://launchpad.net/~openstack
> <https://launchpad.net/%7Eopenstack>
> More help : https://help.launchpad.net/ListHelp
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp

jrd at redhat

Aug 13, 2012, 11:49 AM

Post #21 of 28 (376 views)
Permalink

Re: [Quantum] Removing quantum-rootwrap [In reply to]

> From: jrd [at] redhat
> Date: Fri, 10 Aug 2012 11:52:49 -0400
[...]
> Very much, thanks. More news as it happens...

Here's where I've got to so far

I've ported/transliterated code from nova/cinder to manage rootwrap
filter defs the same way in quantum.

I've plowed through most of the quantum filter defs which were
embedded in the agent code, and changed them to newer format, in
/etc/quantum/rootwrap.d/*

Current headache is getting my test environment back to working
condition, and then contriving enough tests to prove that the code
changes are working. Once I get that done, I'll do a cleanup pass and
get a changeset posted for review.

We're getting close to the tomorrow deadline. I will work with Gary
and Bob and Chris to try to get this stuff nailed ASAP, or figure out
plan B if it looks like that's just too much of a stretch.

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

vishvananda at gmail

Aug 13, 2012, 12:51 PM

Post #22 of 28 (372 views)
Permalink

Re: [Quantum] Removing quantum-rootwrap [In reply to]

This is up to dan, I suppose, but the rootwrap stuff seems like something worth granting a ffe to�

Vish

On Aug 13, 2012, at 11:49 AM, jrd [at] redhat wrote:

>> From: jrd [at] redhat
>> Date: Fri, 10 Aug 2012 11:52:49 -0400
> [...]
>> Very much, thanks. More news as it happens...
>
> Here's where I've got to so far
>
> I've ported/transliterated code from nova/cinder to manage rootwrap
> filter defs the same way in quantum.
>
> I've plowed through most of the quantum filter defs which were
> embedded in the agent code, and changed them to newer format, in
> /etc/quantum/rootwrap.d/*
>
> Current headache is getting my test environment back to working
> condition, and then contriving enough tests to prove that the code
> changes are working. Once I get that done, I'll do a cleanup pass and
> get a changeset posted for review.
>
> We're getting close to the tomorrow deadline. I will work with Gary
> and Bob and Chris to try to get this stuff nailed ASAP, or figure out
> plan B if it looks like that's just too much of a stretch.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

dan at nicira

Aug 13, 2012, 1:11 PM

Post #23 of 28 (372 views)
Permalink

Re: [Quantum] Removing quantum-rootwrap [In reply to]

On Mon, Aug 13, 2012 at 12:51 PM, Vishvananda Ishaya
<vishvananda [at] gmail>wrote:

> This is up to dan, I suppose, but the rootwrap stuff seems like something
> worth granting a ffe to�
>

I wasn't going to mention it, as the urgency of a nearby deadline can be
helpful :)

But yes, I'd grant an ffe to something this important, especially because
it applies across all uses of quantum.

Dan

>
> Vish
>
> On Aug 13, 2012, at 11:49 AM, jrd [at] redhat wrote:
>
> >> From: jrd [at] redhat
> >> Date: Fri, 10 Aug 2012 11:52:49 -0400
> > [...]
> >> Very much, thanks. More news as it happens...
> >
> > Here's where I've got to so far
> >
> > I've ported/transliterated code from nova/cinder to manage rootwrap
> > filter defs the same way in quantum.
> >
> > I've plowed through most of the quantum filter defs which were
> > embedded in the agent code, and changed them to newer format, in
> > /etc/quantum/rootwrap.d/*
> >
> > Current headache is getting my test environment back to working
> > condition, and then contriving enough tests to prove that the code
> > changes are working. Once I get that done, I'll do a cleanup pass and
> > get a changeset posted for review.
> >
> > We're getting close to the tomorrow deadline. I will work with Gary
> > and Bob and Chris to try to get this stuff nailed ASAP, or figure out
> > plan B if it looks like that's just too much of a stretch.
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack
> > Post to : openstack [at] lists
> > Unsubscribe : https://launchpad.net/~openstack
> > More help : https://help.launchpad.net/ListHelp
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~

thierry at openstack

Aug 14, 2012, 1:54 AM

Post #24 of 28 (367 views)
Permalink

Re: [Quantum] Removing quantum-rootwrap [In reply to]

Dan Wendlandt wrote:
> On Mon, Aug 13, 2012 at 12:51 PM, Vishvananda Ishaya
> <vishvananda [at] gmail <mailto:vishvananda [at] gmail>> wrote:
>
> This is up to dan, I suppose, but the rootwrap stuff seems like
> something worth granting a ffe to�
>
>
> I wasn't going to mention it, as the urgency of a nearby deadline can be
> helpful :)
>
> But yes, I'd grant an ffe to something this important, especially
> because it applies across all uses of quantum.

On one hand it's a change that impacts almost all use cases, so
definitely not something that is simple or self-contained. On the other,
it's quite easy to trace back issues to this. In summary, if it's the
only exception in Quantum, it's not really a problem :)

[warning: a trick is included in the last paragraph]

--
Thierry Carrez (ttx)
Release Manager, OpenStack

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

dan at nicira

Aug 14, 2012, 3:22 PM

Post #25 of 28 (362 views)
Permalink

Re: [Quantum] Removing quantum-rootwrap [In reply to]

On Tue, Aug 14, 2012 at 1:54 AM, Thierry Carrez <thierry [at] openstack>wrote:

> Dan Wendlandt wrote:
> > On Mon, Aug 13, 2012 at 12:51 PM, Vishvananda Ishaya
> > <vishvananda [at] gmail <mailto:vishvananda [at] gmail>> wrote:
> >
> > This is up to dan, I suppose, but the rootwrap stuff seems like
> > something worth granting a ffe to�
> >
> >
> > I wasn't going to mention it, as the urgency of a nearby deadline can be
> > helpful :)
> >
> > But yes, I'd grant an ffe to something this important, especially
> > because it applies across all uses of quantum.
>
> On one hand it's a change that impacts almost all use cases, so
> definitely not something that is simple or self-contained. On the other,
> it's quite easy to trace back issues to this. In summary, if it's the
> only exception in Quantum, it's not really a problem :)
>
> [warning: a trick is included in the last paragraph]
>

ttx, I caught it.... I'm on to your project management jedi mind tricks :)

jrd, my feeling is that we'd need a patch for this under review this week
to understand the magnitude of the changes if we want to consider if for a
feature-freeze exception. Thanks.

dan

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

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads