<div dir="ltr">Hi Sumit,<div><br></div><div>First I want to say I'm not opposed to GBP itself, but has many confusion about it's core resource model and how it will integrate with neutron core.</div><div><br></div>
<div>Do you mean for whatever GBP backend configured in any future Neutron deployment, so long as they are in tree, then ML2 core plugin shall always be there to expose the Neutron core resource: Network/Subnet/Port?</div>

<div><br></div><div>Then since Network/Subnet/Port will never be treated just as LEGACY COMPATIBLE role, there is no need to extend Nova-Neutron interface to follow the GBP resource. Anyway, one of optional service plugins inside Neutron shouldn't has any impact on Nova side.</div>
<div><br></div><div>If we agree on this point, core model of GBP should be reviewed, but not just focus on naming convention whether it should be called EP or policy target, then leaving some words here to emphasize GBP is only complementary. In fact, EP/EPG/BD/RD has been designed to be ABLE TO REPLACE Neutron core resource, with mapping as the first step to keep compatible.</div>
<div><br></div><div>In fact, if Neutron core source shall never to be swapped out, GBP core object could be greatly simplified, because mapping already means redundancy :-) Only policy-group is meaningful, behind which are very important policy concept: consumer/producer contracts. After PG is defined, it should be directly applied to existing Neutron core resource, but not create similar concept of EP/L2P/L3P, then mapping to them. Mapping is redundant, and I can understand it's necessity only if someday those neutron core resource are planned to be swapped out.</div>
<div><br></div><div>Simple conclusion: if GBP is just an optional complementary, then after defining policy template, directly APPLYING, but not create similar redundant resource and then MAPPING it to existing neutron core resource.</div>

<div><br></div><div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Aug 9, 2014 at 3:35 AM, 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>On 08/08/2014 12:29 PM, Sumit Naiksatam wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Hi Jay, To extend Ivar's response here, the core resources and core<br>
plugin configuration does not change with the addition of these<br>
extensions. The mechanism to implement the GBP extensions is via a<br>
service plugin. So even in a deployment where a GBP service plugin is<br>
deployed with a driver which interfaces with a backend that perhaps<br>
directly understands some of the GBP constructs, that system would<br>
still need to have a core plugin configured that honors Neutron's core<br>
resources. Hence my earlier comment that GBP extensions are<br>
complementary to the existing core resources (in much the same way as<br>
the existing extensions in Neutron).<br>
</blockquote>
<br></div>
OK, thanks Sumit. That clearly explains things for me.<br>
<br>
Best,<br>
-jay<div><div><br>
<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></div></div>