<div class="gmail_quote">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 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.  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>

<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.<br>

<br>-- <br>Ian.<br><br></div></div>