Re: [Openstack] [Quantum] Removing quantum-rootwrap
From: j...@redhat.com Date: Tue, 14 Aug 2012 20:23:52 -0400 From: Dan Wendlandt d...@nicira.com Date: Tue, 14 Aug 2012 15:22:31 -0700 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. Got it. Update: Dan and ttx, Gary has uploaded a patch set addressing the fix of quantum-rootwrap for me, until I finish getting my credentials sorted out so that I can push them myself. See https://review.openstack.org/11472 There's a couple of review comments, which I will address. What's your inclination? Have we come close enough to the deadline to justify getting this in for f-3, or should we hold off and treat it as a bug later? ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Quantum] Removing quantum-rootwrap
j...@redhat.com wrote: Update: Dan and ttx, Gary has uploaded a patch set addressing the fix of quantum-rootwrap for me, until I finish getting my credentials sorted out so that I can push them myself. See https://review.openstack.org/11472 There's a couple of review comments, which I will address. What's your inclination? Have we come close enough to the deadline to justify getting this in for f-3, or should we hold off and treat it as a bug later? F3 branch was cut, so it's too late for that... But if you're close then we should consider it a bug and fix it before RC1. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Quantum] Removing quantum-rootwrap
Dan Wendlandt wrote: On Mon, Aug 13, 2012 at 12:51 PM, Vishvananda Ishaya vishvana...@gmail.com mailto:vishvana...@gmail.com 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@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Quantum] Removing quantum-rootwrap
On Tue, Aug 14, 2012 at 1:54 AM, Thierry Carrez thie...@openstack.orgwrote: Dan Wendlandt wrote: On Mon, Aug 13, 2012 at 12:51 PM, Vishvananda Ishaya vishvana...@gmail.com mailto:vishvana...@gmail.com 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@lists.launchpad.net 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@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Quantum] Removing quantum-rootwrap
From: Dan Wendlandt d...@nicira.com Date: Tue, 14 Aug 2012 15:22:31 -0700 On Tue, Aug 14, 2012 at 1:54 AM, Thierry Carrez thie...@openstack.org wrote: Dan Wendlandt wrote: On Mon, Aug 13, 2012 at 12:51 PM, Vishvananda Ishaya vishvana...@gmail.com mailto:vishvana...@gmail.com 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. Got it. I apologise that this is taking longer than I hoped. I'm still spending more time on learning curve than getting real productive stuff done. I suppose some of that's to be expected, but still. I spent most of today getting my test env up to snuff, getting more unit test infra written, and then trying to work out how to debug the unit tests. My python-debugging techniques are rusty, so I have to feel my way through. I'll work with the local RH contingent tomorrow. If I can get my new unit tests to behave, I *hope* to be able to run the rest of the suite through in relatively short time. cross fingers If you (Dan and ttx) start feeling like we're just too tight, please say so, and we'll work out plan B. Until then, I'm going to keep banging on this to pull it together. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Quantum] Removing quantum-rootwrap
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 thie...@openstack.org mailto:thie...@openstack.org 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@lists.launchpad.net mailto:openstack@lists.launchpad.net 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@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Quantum] Removing quantum-rootwrap
From: j...@redhat.com 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@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Quantum] Removing quantum-rootwrap
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, j...@redhat.com wrote: From: j...@redhat.com 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@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Quantum] Removing quantum-rootwrap
On Mon, Aug 13, 2012 at 12:51 PM, Vishvananda Ishaya vishvana...@gmail.comwrote: 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, j...@redhat.com wrote: From: j...@redhat.com 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@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net 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@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Quantum] Removing quantum-rootwrap
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 thie...@openstack.orgwrote: 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@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Quantum] Removing quantum-rootwrap
From: Thierry Carrez thie...@openstack.org 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@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Quantum] Removing quantum-rootwrap
From: Thierry Carrez thie...@openstack.org Date: Fri, 10 Aug 2012 17:38:52 +0200 j...@redhat.com 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@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Quantum] Removing quantum-rootwrap
j...@redhat.com wrote: From: Dan Wendlandt d...@nicira.com 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@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Quantum] Removing quantum-rootwrap
From: Thierry Carrez thie...@openstack.org Date: Thu, 09 Aug 2012 10:34:17 +0200 j...@redhat.com wrote: From: Dan Wendlandt d...@nicira.com 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@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Quantum] Removing quantum-rootwrap
j...@redhat.com 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@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Quantum] Removing quantum-rootwrap
From: Thierry Carrez thie...@openstack.org Date: Thu, 09 Aug 2012 16:32:23 +0200 j...@redhat.com 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@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Quantum] Removing quantum-rootwrap
On 08/09/2012 10:32 AM, Thierry Carrez wrote: j...@redhat.com 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@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Quantum] Removing quantum-rootwrap
On Aug 9, 2012, at 8:13 AM, Robert Kukura rkuk...@redhat.com 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@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Quantum] Removing quantum-rootwrap
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 thie...@openstack.org 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@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Quantum] Removing quantum-rootwrap
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@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Quantum] Removing quantum-rootwrap
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@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Quantum] Removing quantum-rootwrap
On Wed, Aug 8, 2012 at 9:22 AM, Thierry Carrez thie...@openstack.orgwrote: 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@lists.launchpad.net 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@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Quantum] Removing quantum-rootwrap
From: Dan Wendlandt d...@nicira.com Date: Wed, 8 Aug 2012 10:28:37 -0700 On Wed, Aug 8, 2012 at 9:22 AM, Thierry Carrez thie...@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. 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@lists.launchpad.net 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
Re: [Openstack] [Quantum] Removing quantum-rootwrap
On Wed, Aug 8, 2012 at 1:20 PM, j...@redhat.com 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@lists.launchpad.net 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@lists.launchpad.net 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@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
