Open Stack

I did not notice Bob already filed a blueprint.
This is good for me as it saves me some time :)

Do you have already a plan for delivering this work item? Let me know if I
can help in any way.

Salvatore

On 9 November 2012 15:26, Salvatore Orlando <sorlando at nicira.com> wrote:

> 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/d123a27e/attachment.html>