[openstack-dev] [Neutron][L3] Representing a networks connected by routers
blak111 at gmail.com
Thu Jul 23 14:51:01 UTC 2015
>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" <carl at ecbaldwin.net> wrote:
> 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
> >> east-west routing between them.
> > Not quite. Multiprovider is to describe different L2 segments that are
> > 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
> > what we are looking to achieve because all of the segments are supposed
> > be part of the same broadcast domain so there is only one DHCP instance
> > all segments, subnets are shared between all of them, a router only
> > to one, etc.
> I share Kevin's understanding of multi-provider networks. Well-stated,
> >>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
> > node so the port creation request should already have the host_id field
> 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.
> > 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?
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev