>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?
Right, that's a big mess. Once a network is picked for a port I think we just need to rely on a scheduler filter that limits the migration to where that network is available. On Jul 23, 2015 8:28 AM, "Carl Baldwin" <c...@ecbaldwin.net> wrote: > 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 >
__________________________________________________________________________ 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
