<div dir="ltr">Hi Jay,<div><br></div><div>You can choose. The whole purpose of this is about flexibility, if you want to use GBP API 'only' with a specific driver you just can.</div><div>Additionally, given the 'ML2 like' architecture, the reference mapping driver can ideally run alongside by filling the core Neutron constructs without ever 'disturbing' your own driver (I'm not entirely sure about this but it seems feasible).</div>
<div><br></div><div>I hope this answers your question,</div><div>Ivar.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 8, 2014 at 6:28 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="">On 08/08/2014 08:55 AM, Kevin Benton wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The existing constructs will not change.<br>
</blockquote>
<br></div>
A followup question on the above...<br>
<br>
If GPB API is merged into Neutron, the next logical steps (from what I can tell) will be to add drivers that handle policy-based payloads/requests.<br>
<br>
Some of these drivers, AFAICT, will *not* be deconstructing these policy requests into the low-level port, network, and subnet creation/attachment/detachment commands, but instead will be calling out as-is to hardware that speaks the higher-level abstraction API [1], not the lower-level port/subnet/network APIs. The low-level APIs would essentially be consumed entirely within the policy-based driver, which would effectively mean that the only way a system would be able to orchestrate networking in systems using these drivers would be via the high-level policy API.<br>
<br>
Is that correct? Very sorry if I haven't explained clearly my question... this is a tough question to frame eloquently :(<br>
<br>
Thanks,<br>
-jay<br>
<br>
[1] <a href="http://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/index.html" target="_blank">http://www.cisco.com/c/en/us/<u></u>solutions/data-center-<u></u>virtualization/application-<u></u>centric-infrastructure/index.<u></u>html</a><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
On Aug 8, 2014 9:49 AM, "CARVER, PAUL" <<a href="mailto:pc2929@att.com" target="_blank">pc2929@att.com</a><br></div><div><div class="h5">
<mailto:<a href="mailto:pc2929@att.com" target="_blank">pc2929@att.com</a>>> wrote:<br>
<br>
Wuhongning [mailto:<a href="mailto:wuhongning@huawei.com" target="_blank">wuhongning@huawei.com</a><br>
<mailto:<a href="mailto:wuhongning@huawei.com" target="_blank">wuhongning@huawei.com</a>><u></u>] wrote:<br>
<br>
>Does it make sense to move all advanced extension out of ML2, like<br>
security<br>
>group, qos...? Then we can just talk about advanced service<br>
itself, without<br>
>bothering basic neutron object (network/subnet/port)<br>
<br>
A modular layer 3 (ML3) analogous to ML2 sounds like a good idea. I<br>
still<br>
think it's too late in the game to be shooting down all the work<br>
that the<br>
GBP team has put in unless there's a really clean and effective way of<br>
running AND iterating on GBP in conjunction with Neutron without being<br>
part of the Juno release. As far as I can tell they've worked really<br>
hard to follow the process and accommodate input. They shouldn't have<br>
to wait multiple more releases on a hypothetical refactoring of how<br>
L3+ vs<br>
L2 is structured.<br>
<br>
But, just so I'm not making a horrible mistake, can someone reassure me<br>
that GBP isn't removing the constructs of network/subnet/port from<br>
Neutron?<br>
<br>
I'm under the impression that GBP is adding a higher level abstraction<br>
but that it's not ripping basic constructs like network/subnet/port out<br>
of the existing API. If I'm wrong about that I'll have to change my<br>
opinion. We need those fundamental networking constructs to be present<br>
and accessible to users that want/need to deal with them. I'm viewing<br>
GBP as just a higher level abstraction over the top.<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></div></div>
<mailto:<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.<u></u>openstack.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><div class=""><br>
<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>
<br>
</div></blockquote><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>