<div dir="ltr">Vendors swapping out components is only one possibility. Once people use this declarative model, optimizations can be made on the reference side as well. ACLs can be placed on L3 agents to reduce the rule count on individual compute nodes, etc. Everyone benefits from the abstraction, not just hardware vendors.<div>

<br></div><div>We don't use SQL because Oracle or Microsoft have good optimizations. We use it because it lets people say what they want without worrying about how it happens.</div></div><div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Wed, Aug 6, 2014 at 2:27 PM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@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 class="HOEnZb"><div class="h5">On 08/06/2014 04:13 PM, Sumit Naiksatam wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton <<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I believe the referential security group rules solve this problem (unless<br>
I'm not understanding):<br>
</blockquote>
<br>
I think the disconnect is that you are comparing the way to current mapping<br>
driver implements things for the reference implementation with the existing<br>
APIs. Under this light, it's not going to look like there is a point to this<br>
code being in Neutron since, as you said, the abstraction could happen at a<br>
client. However, this changes once new mapping drivers can be added that<br>
implement things differently.<br>
<br>
Let's take the security groups example. Using the security groups API<br>
directly is imperative ("put a firewall rule on this port that blocks this<br>
IP") compared to a higher level declarative abstraction ("make sure these<br>
two endpoints cannot communicate"). With the former, the ports must support<br>
security groups and there is nowhere except for the firewall rules on that<br>
port to implement it without violating the user's expectation. With the<br>
latter, a mapping driver could determine that communication between these<br>
two hosts can be prevented by using an ACL on a router or a switch, which<br>
doesn't violate the user's intent and buys a performance improvement and<br>
works with ports that don't support security groups.<br>
<br>
Group based policy is trying to move the requests into the declarative<br>
abstraction so optimizations like the one above can be made.<br>
<br>
</blockquote>
<br>
Kevin, you have captured the GBP value prop and difference very<br>
succinctly. The major difference is in the declarative (GBP) versus<br>
imperative (current) style of programming.<br>
<br>
This has been stated very clearly and explicitly in the blueprint<br>
spec. If one does not appreciate the difference or advantage of one<br>
over the other, then this discussion is pointless.<br>
</blockquote>
<br></div></div>
"One" does appreciate the value of having porcelain APIs overlay a plumbing API. This discussion was about the proper way and place to introduce such functionality.<br>
<br>
However, it seems to me that the end-goal of the GBP effort is *actually* to provide a higher-layer API to Neutron that would essentially enable proprietary vendors to entirely swap out all of Neutron core for a new set of drivers that spoke proprietary device APIs.<br>


<br>
If this is the end-goal, it should be stated more clearly, IMO.<br>
<br>
The classic plumbing versus porcelain API conversation [1] is a good one, and one worth having in the context of Neutron.<br>
<br>
It's almost like some Neutron contributor folks are saying "let's add a porcelain API so we can ditch all the existing plumbing APIs and replace with our own stuff". And that's not what the point of plumbing vs. porcelain is.<br>


<br>
-jay<br>
<br>
[1] <a href="http://git-scm.com/book/en/Git-Internals-Plumbing-and-Porcelain" target="_blank">http://git-scm.com/book/en/<u></u>Git-Internals-Plumbing-and-<u></u>Porcelain</a><div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Kevin Benton</div>
</div>