Open Stack

Hi again,

Network creation does not, and will not, imply a Layer 3 network. Quantum
will continue to support L-2 only domains, and this is what you will get
when you create a network.

On the "infamous" routed insertion mode, I think it's been interpreted in
all the possible ways from the community, but unfortunately not in the way
it was originally proposed. Anyway, it won't definitely be the only way of
plugging 'advanced' services in a quantum network.

It is my opinion the framework of network services exposed by Quantum,
intended as the set of services offered to final users, will grow over the
course of several releases, and will eventually encompass all the services
highlighted in Alan's comprehensive diagram. Taking the current
implementation of the L3 API extension, and splitting it over one or more
plugins is surely an important step, and in my opinion is orthogonal to the
discussion about how these services should be place in the tenant's logical
topology.

A question worth asking is whether the L3 API, which provides l3
forwarding, external gw through SNAT, and floating IPs through DNAT, should
all be implemented by a single plugin, or whether there's actually the case
for multiple independent plugins.

Salvatore



On 9 November 2012 23:43, Alan Kavanagh <alan.kavanagh at ericsson.com> wrote:

>  So I believe that’s a very good point and one I firmly support, we
> should not enforce that issuing a Create_network implies you do an L-3
> network and does not imply you tie this network to a router, fully agree we
> should avoid that as depending on the Virtual Networking Services you want
> to add that will then determine the need for other Networking Services such
> as a “Router”.****
>
> ** **
>
> Alan****
>
> ** **
>
> *From:* Salvatore Orlando [mailto:sorlando at nicira.com]
> *Sent:* November-09-12 9:27 AM
>
> *To:* OpenStack Development Mailing List
> *Subject:* Re: [openstack-dev] Quantum L3 router, mixin or plugin?****
>
> ** **
>
> 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****
>
>  ** **
>
> _______________________________________________
> 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/20121110/20ab918c/attachment.html>