<div>Hello again!</div>Comments inline<div><br></div><div>Salvatore<br><br><div class="gmail_quote">On 12 November 2012 12:04, Bob Melander (bmelande) <span dir="ltr"><<a href="mailto:bmelande@cisco.com" target="_blank">bmelande@cisco.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word">
<div>My original thinking (given that others would agree that separate plugin(s) for L3/routing is a good idea, and it seems people do) was to start modestly by simply refactoring the mixin to become a plugin, adhering to the SI framework being developed. Getting
 that into Grizzly would be a good baseline. I think this is also what you were proposing in your "9 november 2012 13:56" email? </div></div></blockquote><div><br></div><div>Agreed. In a previous email I had a comment concerning xxx_l3_yyy functions in the base plugins. Some people who read this thread misunderstood this as entangling L2 and L3 concepts in a way such that a network would be always associated with a L3 forwarding element. This kind of brought the thread a little bit off topic. I think your last paragraph summarises very well our goal.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word"><div>I'm willing to do work on this, or actually I am doing work on it already that hopefully can be of use. I understand you're going
 to migrate the L3 API to core and these two efforts clearly have connections.</div></div></blockquote><div><br></div><div>If you look at the service insertion patch on gerrit, one assumption there is that there is a 1:1 relationship between API extensions and services. While this works well for 'new' services which will be inserted as API extension, will need some more thought from us on how to wire something which is part of core API onto the new l3 plugin. Also, I am not sure we want to have a URI prefix for router and floating IP operations, as currently required by the SI framework, due to backward compatibiltiy reasons.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word">
<div><br>
</div>
<div>About your comment/question about further decomposing the different L3 routing functionality into separate L3 plugins, my spontaneous proposal is to keep it as one plugin for now. Then as discussions and work evolve on the L3 APIs, VPNs, NAT etc we can
 revisit this and make further splits if that turns out to make sense.</div></div></blockquote><div><br></div><div>I totally agree, that was my thinking too. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word">
<div><br>
</div>
<div>/ Bob</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<span>
<div style="border-right:medium none;padding-right:0in;padding-left:0in;padding-top:3pt;text-align:left;font-size:11pt;border-bottom:medium none;font-family:Calibri;border-top:#b5c4df 1pt solid;padding-bottom:0in;border-left:medium none">

<span style="font-weight:bold">From: </span>Salvatore Orlando <<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>><div class="im"><br>
<span style="font-weight:bold">Reply-To: </span>OpenStack Development Mailing List <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
</div><span style="font-weight:bold">Date: </span>fredag 9 november 2012 15:35<br>
<span style="font-weight:bold">To: </span>OpenStack Development Mailing List <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><div class="im"><br>
<span style="font-weight:bold">Subject: </span>Re: [openstack-dev] Quantum L3 router, mixin or plugin?<br>
</div></div><div><div class="h5">
<div><br>
</div>
<div>
<div>I did not notice Bob already filed a blueprint.
<div>This is good for me as it saves me some time :)</div>
<div><br>
</div>
<div>Do you have already a plan for delivering this work item? Let me know if I can help in any way.</div>
<div><br>
</div>
<div>Salvatore</div>
<div><br>
<div class="gmail_quote">On 9 November 2012 15:26, Salvatore Orlando <span dir="ltr">
<<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Replies inline.<br>
<br>
<div class="gmail_quote">
<div>On 9 November 2012 15:03, Ian Wells <span dir="ltr"><<a href="mailto:ijw.ubuntu@cack.org.uk" target="_blank">ijw.ubuntu@cack.org.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote">
<div>On 9 November 2012 12:42, Bob Melander (bmelande) <span dir="ltr"><<a href="mailto:bmelande@cisco.com" target="_blank">bmelande@cisco.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div style="font-family:Calibri,sans-serif;font-size:14px">Ok, I'm willing to work on this and I've created a blueprint to kick it off (<a href="https://blueprints.launchpad.net/quantum/+spec/quantum-l3-routing-plugin" target="_blank">https://blueprints.launchpad.net/quantum/+spec/quantum-l3-routing-plugin</a>)</div>

<div style="font-family:Calibri,sans-serif;font-size:14px"><br>
</div>
<div style="font-family:Calibri,sans-serif;font-size:14px">I too think VRRP (and some other features) would be nice to add. However, the first steps would be to take the inherited mixin and transform that into a plugin. That ought to be possible with fairly
 limited effort. Though there are some dependencies that need to be sorted out. In particular, core plugin methods like <span style="font-family:Helvetica;font-size:12px"> <span style="font:normal normal normal 12px/normal Courier">create_network(…)</span></span>make
 calls to mixin functions such as <span style="font-family:Helvetica;font-size:12px"><span style="font:12.0px Courier">_process_l3_create(…), _extend_network_dict_l3(…), _process_l3_update(…)</span><span style="font:12.0px Courier">:</span></span></div>

<p style="font-family:Calibri,sans-serif;font-size:14px;margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;font:normal normal normal 12px/normal Courier;min-height:14px">
<br>
</p>
<p style="font-family:Calibri,sans-serif;font-size:14px;margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;font:normal normal normal 12px/normal Courier">
self._process_l3_create(context, network['network'], net['id'])</p>
<p style="font-family:Calibri,sans-serif;font-size:14px;margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;font:normal normal normal 12px/normal Courier">
…</p>
<p style="font-family:Calibri,sans-serif;font-size:14px;margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;font:normal normal normal 12px/normal Courier">
self._extend_network_dict_l3(context, net)</p>
</div>
</blockquote>
</div>
<div style="border-right:medium none;padding-right:0in;padding-left:0in;padding-top:3pt;text-align:left;font-size:11pt;border-bottom:medium none;font-family:Calibri;border-top:#b5c4df 1pt solid;padding-bottom:0in;border-left:medium none">

<br>
One point here is that I would like to be able to create an unrouted network.  Creating a network *with* a router is a composite call (and in any case, shouldn't I be able to create a network and add a router later on?) and I don't think that functionality
 should be baked into create_network if we can avoid it. </div>
</div>
</blockquote>
<div><br>
</div>
</div>
<div>That how we do it, actually.</div>
<div><br>
</div>
<div>1) POST /networks</div>
<div>Create a l2 network</div>
<div>2) POST /subnets with reference in body to previously created network</div>
<div>Defines a IP address range on the L2 network</div>
<div>3) POST /routers</div>
<div>Defined a l3 forwarding element</div>
<div>4) PUT /routers/<router-id>/add-router-interface</div>
<div>Connects a subnet to a router</div>
<div>
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote">
<div style="border-right:medium none;padding-right:0in;padding-left:0in;padding-top:3pt;text-align:left;font-size:11pt;border-bottom:medium none;font-family:Calibri;border-top:#b5c4df 1pt solid;padding-bottom:0in;border-left:medium none">

I'm aware this breaks backward compatibility in the way I've described it, but just my 2c.  (Perhaps create_network becomes a thin wrapper over a more fundamental call, create_bare_network?)<br>
</div>
</div>
</blockquote>
<div><br>
</div>
</div>
<div>The methods pointed out by Bob are not really for creating a router with a network; they are for managing the additions that the l3 API extensions makes to the "network" resource in order to handle "external" networks properly. I have more on then in my
 previous post.</div>
<div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote">
<div style="border-right:medium none;padding-right:0in;padding-left:0in;padding-top:3pt;text-align:left;font-size:11pt;border-bottom:medium none;font-family:Calibri;border-top:#b5c4df 1pt solid;padding-bottom:0in;border-left:medium none">

<br>
There's reasons why you might want that: in a layered application, HA -> cache -> web appservers  -> DB for instance, most of the inner networks you might create for such a topology have no need of external routeability.  At the moment the rule seems to be
 'if you don't need it, don't use it' but it would be nice to simply not have the router there in the first place.</div>
</div>
</blockquote>
<div><br>
</div>
</div>
<div>Totally agree. Quantum v1 actually did not have any router and built multi-tier topologies as you describe them. The router is not necessary, and if you don't need it it does not get created.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote">
<div style="border-right:medium none;padding-right:0in;padding-left:0in;padding-top:3pt;text-align:left;font-size:11pt;border-bottom:medium none;font-family:Calibri;border-top:#b5c4df 1pt solid;padding-bottom:0in;border-left:medium none">

<span><font color="#888888"><br>
<span><font color="#888888"><br>
-- <br>
Ian.<br>
<br>
</font></span></font></span></div>
</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>
</div>
</blockquote>
</div>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div></div></span>
</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>