On 03/21/2014 10:42 AM, Thierry Carrez wrote:
Yuriy Taraday wrote:
On Thu, Mar 20, 2014 at 5:41 PM, Miguel Angel Ajo <majop...@redhat.com
<mailto:majop...@redhat.com>> wrote:
If this coupled to neutron in a way that it can be accepted for
Icehouse (we're killing a performance bug), or that at least it can
be y backported, you'd be covering both the short & long term needs.
As I said on the meeting I plan to provide change request to Neutron
with some integration with this patch.
I'm also going to engage people involved in rootwrap about my change
request.
Temporarily removing my rootwrap maintainer hat and putting on my
OpenStack release manager hat: as you probably know we are well into
Icehouse feature freeze at this point, and there is no way I would
consider such a significant change for inclusion in the Icehouse release
at this point.
The work on both the daemon and the shedskin stuff is very promising,
but the nature of this beast makes it necessary to undergo a lot of
testing and security audits before it can be accepted. Not exactly
something I'd consider 4 weeks before a final release.
Frankly, this issue has been on the table forever and this is just the
wrong timing to rush a new implementation to fix it.
Thierry, it sounds reasonable to me, even if this is a bug that we're
trying to kill (and not a new feature), the regressions and security
problems it could come with totally justify that reasoning.
I'd be satisfied if the implementation Yuriy is preparing could be done
in a way that:
1) The traditional sudo/rootwrap functionality is preserved
2) it can be backported to icehouse/havana if it does work as we expect
and the security sounds reasonable.
1: would allow falling back to a C/translated implementation, which
looks like it will be more expensive to develop & maintain for the
same/very similar performance results.
2: would fix our short-term problem with Icehouse.
I filed a rootwrap session for the Juno Design summit -- ideally we'll
have various solutions ready by then and we'd make the final choice for
early integration in Juno, leaving plenty of time to catch the weird
regressions (or security holes) that it may cause.
Best,
Miguel Ángel.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
