Open Stack

Replies inline.

On 9 November 2012 15:03, Ian Wells <ijw.ubuntu at cack.org.uk> wrote:

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

That how we do it, actually.

1) POST /networks
Create a l2 network
2) POST /subnets with reference in body to previously created network
Defines a IP address range on the L2 network
3) POST /routers
Defined a l3 forwarding element
4) PUT /routers/<router-id>/add-router-interface
Connects a subnet to a router



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

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.


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

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.


>
>
> --
> Ian.
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121109/30cb252f/attachment.html>