On Wed, Jul 22, 2015 at 3:00 PM, Kevin Benton <blak...@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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
