<div dir="ltr">I was asked beforehand what I mean with<div><br></div><div>* <span style="font-family:arial,sans-serif;font-size:13px">consider GBP an 'experimental' V3 tenant API (this was mentioned somewhere in this thread) and treat it accordingly</span></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">The group based policies, although implemented as a service plugin, are quite different from the ones we have now. Things like firewall, load balancer, etc. add something that will be run alongside the "core" API. This service plugin instead define a different kind of abstractive (declarative vs imperative as it has been mentioned several times) and it won't be wrong to say it can replace the core API. To this aim I think it's fair to consider it an experimentation around a new tenant API.</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">In this hypothesis, how should this be treated? The decision ultimately does not lie with me.</font></div><div><font face="arial, sans-serif">I would merely point out that:</font></div>
<div><font face="arial, sans-serif">1) The neutron core team should not stop innovation. If a consistent part of the community feels that a declarative base model is that way forward and we should experiment with it, than we should do everything we can to help this part of the community.</font></div>
<div><font face="arial, sans-serif">2) On the other hand, innovation and experimentation should not deprive the core team of significant resources which should be directed first and foremost to address the areas identified by the TC as in need of improvement</font></div>
<div>In the light of the above, and reflecting on the ultimate question which is whether this code should be merged or not. Allow me to say that my final thought is that I don't care whether is merged in the main neutron repo or somewhere else, as long as it does not constitute additional burden for the core team in terms of reviews, maintainability, gate failures (it won't be the first time I or other core team members had to chase failures for some service plugins digging into logs), and future design decisions (ie: having to ask the question - "what about group policy" for every future API decision)</div>
<div><br></div><div>Salvatore</div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">PS: did I make post #100?<br></font><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On 7 August 2014 00:47, Kevin Benton <span dir="ltr"><<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">I think we should merge it and just prefix the API for now with '/your_application_will_break_after_juno_if_you_use_this/' <br>
</p><div class="HOEnZb"><div class="h5">
<div class="gmail_quote">On Aug 6, 2014 4:41 PM, "Armando M." <<a href="mailto:armamig@gmail.com" target="_blank">armamig@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">This thread is moving so fast I can't keep up!<div><br></div><div>The fact that troubles me is that I am unable to grasp how we move forward, which was the point of this thread to start with. It seems we have 2 options:</div>
<div><br></div><div>- We make GBP to merge as is, in the Neutron tree, with some minor revision (e.g. naming?);</div><div>- We make GBP a stackforge project, that integrates with Neutron in some shape or form;</div><div>
<br>
</div><div>Another option, might be something in between, where GBP is in tree, but in some sort of experimental staging area (even though I am not sure how well baked this idea is).</div><div><br></div><div>Now, as a community we all need make a decision; arguing about the fact that the blueprint was approved is pointless. As a matter of fact, I think that blueprint should be approved, if and only if the code has landed completely, but I digress!</div>
<div><br></div><div>Let's together come up with pros and cons of each approach and come up with an informed decision.</div><div><br></div><div>Just reading free form text, how are we expected to do that? At least I can't!</div>
<div><br></div><div>My 2c.</div><div>Armando</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 6 August 2014 15:03, Aaron Rosen <span dir="ltr"><<a href="mailto:aaronorosen@gmail.com" target="_blank">aaronorosen@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div>On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton <span dir="ltr"><<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">I believe the referential security group rules solve this problem (unless I'm not understanding): </span><div>
<span style="font-family:arial,sans-serif;font-size:13.333333969116211px"><br>
</span></div></div><div>I think the disconnect is that you are comparing the way to current mapping driver implements things for the reference implementation with the existing APIs. Under this light, it's not going to look like there is a point to this code being in Neutron since, as you said, the abstraction could happen at a client. However, this changes once new mapping drivers can be added that implement things differently.</div>
<div><br></div><div>Let's take the security groups example. Using the security groups API directly is imperative ("put a firewall rule on this port that blocks this IP") compared to a higher level declarative abstraction ("make sure these two endpoints cannot communicate"). With the former, the ports must support security groups and there is nowhere except for the firewall rules on that port to implement it without violating the user's expectation. With the latter, a mapping driver could determine that communication between these two hosts can be prevented by using an ACL on a router or a switch, which doesn't violate the user's intent and buys a performance improvement and works with ports that don't support security groups.</div>
<div><br></div><div>Group based policy is trying to move the requests into the declarative abstraction so optimizations like the one above can be made.</div></div></blockquote><div><br></div></div></div><div>Hi Kevin, </div>
<div><br>
</div><div>Interesting points. Though, let me ask this. Why do we need to move to a declarative API abstraction in neutron in order to perform this optimization on the backend? For example, In the current neutron model say we want to create a port with a security group attached to it called web that allows TCP:80 in and members who are in a security group called database. >From this mapping I fail to see how it's really any different from the declarative model? The ports in neutron are logical abstractions and the backend system could be implemented in order to determine that the communication between these two hosts could be prevented by using an ACL on a router or switch as well.</div>
<div>
<div><br>Best, </div><div><br></div><div>Aaron</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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></blockquote></div></div><br></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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></blockquote></div><br></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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></blockquote></div>
</div></div><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></blockquote></div><br></div>