<div dir="ltr">Jay<div>Doesnt the current plugin model in neutron work the way you are saying. We have a a core set of APIs that there is a reference model for and individual vendors have substituted plugins that enhance and sometimes replace networking component. GBP in that respect does not change. There is a reference implementation in neutron for declarative model in neutron and vendors can substitute their implementation to enhance what is in reference. </div>
<div><br></div><div>But what you need to understand is the declarative model that it provides which Ryan has elaborated which current neutron does not provide. </div><div><br></div><div>prasadv</div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Wed, Aug 6, 2014 at 1: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></div>