Open Stack

On 20/07/15 18:50, Ian Wells wrote:
> On 20 July 2015 at 10:21, Neil Jerram <Neil.Jerram at metaswitch.com
> <mailto:Neil.Jerram at metaswitch.com>> wrote:
>
>     Hi Ian,
>
>     On 20/07/15 18:00, Ian Wells wrote:
>
>         On 19 July 2015 at 03:46, Neil Jerram
>         <Neil.Jerram at metaswitch.com
>         <mailto:Neil.Jerram at metaswitch.com>
>         <mailto:Neil.Jerram at metaswitch.com
>         <mailto:Neil.Jerram at metaswitch.com>>> wrote:
>
>             The change at [1] creates and describes a new 'routed'
>         value for
>             provider:network_type.  It means that a compute host
>         handles data
>             to/from the relevant TAP interfaces by routing it, and
>         specifically
>             that those TAP interfaces are not bridged.
>
>
>         To clarify that, the user uses provider:network_type in the
>         API to request a 'routed' network be created, and the Neutron
>         plugin either implements that or rejects the create call?  Or
>         something else?
>
>
>     Yes, I believe so.  Could it be otherwise?
>
>
> We can make it work any way you like if you'we willing to spend the
> rest of your life writing it. ;)
>
> It depends rather on how you picture this working. 
>
> As described you've made it so that networks would be routed if the
> admin created them and specifically flagged them as routed, which
> useful for testing, or if the mechdriver is the default, which is
> probably the most useful way in production. 
>
> I think the thing that we'll be missing long term is a means to
> explicitly request an L2 domain - as that's the special case that you
> might explicitly want, the general case is 'with IP addresses my VMs
> can talk to each other' - and that would require more than Neutron
> currently provides and would require work.

Thanks Ian.

When I wrote "Could if be otherwise?" above, I meant in the narrow sense
of "If you've configured a particular ML2 mechanism driver, and that
driver can't handle a particular network_type, can it do anything other
than reject the network creation call?".

But, in the light of the discussion in the "Representing a networks
connected by routers" thread (starting at [1]), I guess you were
thinking more broadly, and it seems clear now that more thinking is
needed about the best way to model this 'routed' networking idea,
consistent with existing Neutron concepts.

[1] http://lists.openstack.org/pipermail/openstack-dev/2015-July/070028.html

Some suggestions, from those discussions:

- A Neutron network is fundamentally an L2 thing, so maybe it's wrong to
model this as multiple VMs attaching to a new kind of Neutron network.

- As the concept is of VMs attaching to a L3 domain, perhaps that should
be modelled as attaching to a subnet, or subnet pool, or address scope. 
Perhaps with a null network in places where a network is currently required.

Two other ideas that occur to me:

- Actually each VM port does still attach to a L2 network (as least in
the sense that the IP is still over Ethernet) - but it's a L2 network
that contains only that port, and is terminated by the corresponding TAP
interface on the compute host.  Could it perhaps be useful to model this
as a Neutron network per VM port?

- Another possible modelling idea is to say that the VMs are being
attached to a Router object.  The Router could have an associated subnet
pool, and then an IP address would be allocated from that pool, for each
VM port.  (Or 2 pools and 2 IP addresses, for v6 as well as v4.)

Any further ideas and thoughts would be much appreciated here!

Many thanks,
    Neil