Open Stack

I would second Maru's concerns, and I would also like to add the following:

We need to acknowledge the fact that there are certain architectural
aspects of Neutron as a project that need to be addressed; at the
summit we talked about the core refactoring, a task oriented API, etc.
To me these items have been neglected far too much over the past and
would need a higher priority and a lot more attention during the Juno
cycle. Being stretched as we are I wonder if dev/review cycles
wouldn't be better spent devoting more time to these efforts rather
than GP.

That said, I appreciate that GP is important and needs to move
forward, but at the same time I am thinking that there must be a
better way for addressing it and yet relieve some of the pressure that
GP complexity imposes to the Neutron team. One aspect it was discussed
at the summit was that the type of approach shown in [2] and [3]
below, was chosen because of lack of proper integration hooks...so I
am advocating: let's talk about those first before ruling them out in
favor of a monolithic approach that seems to violate some engineering
principles, like modularity and loose decoupling of system components.

I think we didn't have enough time during the summit to iron out some
of the concerns voiced here, and it seems like the IRC meeting for
Group Policy would not be the right venue to try and establish a
common ground among the people driving this effort and the rest of the
core team.

Shall we try and have an ad-hoc meeting and an ad-hoc agenda to find a
consensus?

Many thanks,
Armando

On 22 May 2014 11:38, Maru Newby <marun at redhat.com> wrote:
>
> On May 22, 2014, at 11:03 AM, Maru Newby <marun at redhat.com> wrote:
>
>> At the summit session last week for group-based policy, there were many concerns voiced about the approach being undertaken.  I think those concerns deserve a wider audience, and I'm going to highlight some of them here.
>>
>> The primary concern seemed to be related to the complexity of the approach implemented for the POC.  A number of session participants voiced concern that the simpler approach documented in the original proposal [1] (described in the section titled 'Policies applied between groups') had not been implemented in addition to or instead of what appeared in the POC (described in the section titled 'Policies applied as a group API').  The simpler approach was considered by those participants as having the advantage of clarity and immediate usefulness, whereas the complex approach was deemed hard to understand and without immediate utility.
>>
>> A secondary but no less important concern is related to the impact on Neutron of the approach implemented in the POC.  The POC was developed monolithically, without oversight through gerrit, and the resulting patches were excessive in size (~4700 [2] and ~1500 [3] lines).  Such large patches are effectively impossible to review.  Even broken down into reviewable chunks, though, it does not seem realistic to target juno-1 for merging this kind of complexity.  The impact on stability could be considerable, and it is questionable whether the necessary review effort should be devoted to fast-tracking group-based policy at all, let alone an approach that is considered by many to be unnecessarily complicated.
>>
>> The blueprint for group policy [4] is currently listed as a 'High' priority.  With the above concerns in mind, does it make sense to continue prioritizing an effort that at present would seem to require considerably more resources than the benefit it appears to promise?
>>
>>
>> Maru
>>
>> 1: https://etherpad.openstack.org/p/group-based-policy
>
> Apologies, this link is to the summit session etherpad.  The link to the original proposal is:
>
> https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit
>
>> 2: https://review.openstack.org/93853
>> 3: https://review.openstack.org/93935
>> 4: https://blueprints.launchpad.net/neutron/+spec/group-based-policy-abstraction
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev