<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Maru's concerns are that:</div><div class="gmail_default" style="font-size:small">1. It is large</div>
<div class="gmail_default" style="font-size:small">2. It is complex</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">And Armando's related concerns are:</div>
<div class="gmail_default" style="font-size:small">3. Could <span style="font-family:arial,sans-serif;font-size:13px">dev/review cycles </span><span style="font-family:arial,sans-serif;font-size:13px">be better spent on refactoring</span></div>
<div class="gmail_default" style="font-size:small">4. If refactored neutron was available, would a simpler option become more viable</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">
Let me address them in that order.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">1. Re: It is large</div><div class="gmail_default" style="font-size:small">
Group policy has an ambitious goal - provide devop teams with policy based controls that are usable at scale and with automation (say a higher governance layer like Congress). The fact that meeting a large challenge requires more code is natural. We understand that challenge, and that is why we did a prototype (as PoC that was demonstrated on the summit). And based on that learning we are incrementally creating patches for building the group based policy. Just because a task is large, we as neutron can not shy away from building it. That will only drive people who need it out side neutron (as we are seeing with the frustration that the LBaaS team had because they have a requirement that is "large" as well).</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">2. Re: It is complex</div><div class="gmail_default" style="font-size:small">Complexity depends on the context. Our goal was to make the end-user's life simpler (and more automated). To achieve some of that simplicity, we required a little more complexity in the implementation. We decide to make that arbitrage - a little higher complexity in implementation to allow for simpler usage. But we were careful and did not want to impose that complexity on every use case - hence a lot of that is optional (and exercised only if the use case needs it). Unfortunately the model, has to model all of it so as it not add complexity later in upgrade and backward compatibility issues. We choose to do architecture upfront, and then implement it incrementally.</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The team came up with the model currently in model based on that review and evaluation all the proposals in the document that you refer. It is easy to make general comments, but unless you participate in the process and sign up to writing the code, those comments are not going to help with solving the original problem. And this _is_ open-source. If you disagree, please write code and the community can decide for itself as to what model is actually simple to use for them. Curtailing efforts from other developers just because their engineering trade-offs are different from what you believe your use-case needs is not why we like open source. We enjoy the mode where different developers try different things, we experiment, and the software evolves to what the user demands. Or maybe, multiple models live in harmony. Let the users decide that.</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">3. Re: Could <span style="font-size:13px;font-family:arial,sans-serif">dev/review cycles </span><span style="font-size:13px;font-family:arial,sans-serif">be better spent on refactoring</span></div>
<div class="gmail_default"><font face="arial, sans-serif">I think that most people agree that policy control is an important feature that fundamentally improves neutron (by solving the automation and scale issues). In a large project, multiple sub-projects can, and for a healthy project should, work in parallel. I understand that the neutron core team is stretched. But we still need to be able to balance the needs of today (paying off the technical debt/existing-issues by doing refactoring) with needs of tomorrow (new features like GP and LBaaS). GP effort was started in Havana, and now we are trying to get this in Juno. I think that is reasonable and a long enough cycle for a "high priority" project to be able to get some core attention. Again I refer to LBaaS experience, as they struggled with very similar issues.</font></div>
<div class="gmail_default"><font face="arial, sans-serif"><br></font></div><div class="gmail_default"><div class="gmail_default">4. Re: If refactored neutron was available, would a simpler option become more viable</div><div class="gmail_default">
We would love to be able to answer that question. We have been trying to understand the refactoring work to understand this (see another ML thread) and we are open to understanding your position on that. We will call the ad-hoc meeting that you suggested and we would like to understand the refactoring work that might be reused for simpler policy implementation. At the same time, we would like to build on what is available today, and when the required refactored neutron becomes available (say Juno or K-release), we are more than happy to adapt to it at that time. Serializing all development around an effort that is still in inception phase is not a good solution. We are looking forward to participating in the core refactoring work, and based on the final spec that come up with, we would love to be able to eventually make the policy implementation simpler.</div>
<div class="gmail_default"><br></div><div class="gmail_default">Regards,</div><div class="gmail_default">Mandeep</div><div class="gmail_default"><br></div><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Thu, May 22, 2014 at 11:44 AM, Armando M. <span dir="ltr"><<a href="mailto:armamig@gmail.com" target="_blank">armamig@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I would second Maru's concerns, and I would also like to add the following:<br>
<br>
We need to acknowledge the fact that there are certain architectural<br>
aspects of Neutron as a project that need to be addressed; at the<br>
summit we talked about the core refactoring, a task oriented API, etc.<br>
To me these items have been neglected far too much over the past and<br>
would need a higher priority and a lot more attention during the Juno<br>
cycle. Being stretched as we are I wonder if dev/review cycles<br>
wouldn't be better spent devoting more time to these efforts rather<br>
than GP.<br>
<br>
That said, I appreciate that GP is important and needs to move<br>
forward, but at the same time I am thinking that there must be a<br>
better way for addressing it and yet relieve some of the pressure that<br>
GP complexity imposes to the Neutron team. One aspect it was discussed<br>
at the summit was that the type of approach shown in [2] and [3]<br>
below, was chosen because of lack of proper integration hooks...so I<br>
am advocating: let's talk about those first before ruling them out in<br>
favor of a monolithic approach that seems to violate some engineering<br>
principles, like modularity and loose decoupling of system components.<br>
<br>
I think we didn't have enough time during the summit to iron out some<br>
of the concerns voiced here, and it seems like the IRC meeting for<br>
Group Policy would not be the right venue to try and establish a<br>
common ground among the people driving this effort and the rest of the<br>
core team.<br>
<br>
Shall we try and have an ad-hoc meeting and an ad-hoc agenda to find a<br>
consensus?<br>
<br>
Many thanks,<br>
Armando<br>
<div class="HOEnZb"><div class="h5"><br>
On 22 May 2014 11:38, Maru Newby <<a href="mailto:marun@redhat.com">marun@redhat.com</a>> wrote:<br>
><br>
> On May 22, 2014, at 11:03 AM, Maru Newby <<a href="mailto:marun@redhat.com">marun@redhat.com</a>> wrote:<br>
><br>
>> 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.<br>
>><br>
>> 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.<br>
>><br>
>> 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.<br>
>><br>
>> 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?<br>
>><br>
>><br>
>> Maru<br>
>><br>
>> 1: <a href="https://etherpad.openstack.org/p/group-based-policy" target="_blank">https://etherpad.openstack.org/p/group-based-policy</a><br>
><br>
> Apologies, this link is to the summit session etherpad. The link to the original proposal is:<br>
><br>
> <a href="https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit" target="_blank">https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit</a><br>
><br>
>> 2: <a href="https://review.openstack.org/93853" target="_blank">https://review.openstack.org/93853</a><br>
>> 3: <a href="https://review.openstack.org/93935" target="_blank">https://review.openstack.org/93935</a><br>
>> 4: <a href="https://blueprints.launchpad.net/neutron/+spec/group-based-policy-abstraction" target="_blank">https://blueprints.launchpad.net/neutron/+spec/group-based-policy-abstraction</a><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>