Open Stack

On Wed, Jul 22, 2015 at 3:00 PM, Kevin Benton <blak111 at gmail.com> wrote:
>>It seems to me that the existence of the multiprovider extension is an
>> important point for this discussion.  Multiprovider, as I understand it,
>> allows describing a network composed of multiple L2 segments with implicit
>> east-west routing between them.
>
> Not quite. Multiprovider is to describe different L2 segments that are all
> connected together via some kind of translator (e.g. l2 gateway) that
> ensures they are all part of the same broadcast domain. It doesn't fit with
> what we are looking to achieve because all of the segments are supposed to
> be part of the same broadcast domain so there is only one DHCP instance for
> all segments, subnets are shared between all of them, a router only attaches
> to one, etc.

I share Kevin's understanding of multi-provider networks.  Well-stated, Kevin.

>>But I was suggesting that there might be some scenarios where routing
> happened without a corresponding router object, and in fact it appears
> that this is already the case: between the segments of a multiprovider
> network.
>
> There isn't routing between different subnets for multiprovider networks. A
> multiprovider network is just an l2 broadcast domain realized on multiple
> encapsulation mediums.

This was my understanding too.

>>I think Ian's posts have now clarified this.  The current order of
> events is:
>>- Neutron creates an unbound port, associated with a network, and
> allocates an IP address for it.
>>- Nova chooses a host for the new VM.
>>- The port is bound and plugged on that host.
>
> This is only the case if someone passes a port UUID into Nova to use. If
> Nova creates the port itself, it will wait until it's scheduled to a compute
> node so the port creation request should already have the host_id field set.

I like this better than delaying IP address assignment until host
binding occurs.

> Supporting the case a pre-created port and migration will be the issue. We
> would essentially need to allow ports to be re-assigned to different
> networks to handle these scenarios.

Or, migration scheduling would need to respect the constraint that a
port may be confined to a set of hosts.  How can be assign a port to a
different network?  The VM would wake up and what?  How would it know
to reconfigure its network stack?

Carl