Open Stack

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 <majopela at redhat.com
>> <mailto:majopela at 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.