[openstack-dev] Quantum L3 router, mixin or plugin?

Ian Wells ijw.ubuntu at cack.org.uk
Fri Nov 9 14:03:55 UTC 2012


On 9 November 2012 12:42, Bob Melander (bmelande) <bmelande at cisco.com>wrote:

>  Ok, I'm willing to work on this and I've created a blueprint to kick it
> off (
> https://blueprints.launchpad.net/quantum/+spec/quantum-l3-routing-plugin)
>
>  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  create_network(…)make calls to
> mixin functions such as _process_l3_create(…),
> _extend_network_dict_l3(…), _process_l3_update(…):
>
>
>  self._process_l3_create(context, network['network'], net['id'])
>
>>
> self._extend_network_dict_l3(context, net)
>

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?)

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.

-- 
Ian.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121109/5d78d02f/attachment.html>


More information about the OpenStack-dev mailing list