Open Stack

>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
> 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150723/2bcf62c0/attachment.html>