Open Stack

A lot of heat templates precreate the ports though. its sometimes easier to build the template that way.

May not matter too much. Just pointing out its more common then you might think.

Thanks,
Kevin
________________________________________
From: Mike Dorman [mdorman at godaddy.com]
Sent: Monday, July 27, 2015 7:26 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][L3] Representing a networks connected by routers

On 7/23/15, 8:54 AM, "Carl Baldwin" <carl at ecbaldwin.net> wrote:

>On Thu, Jul 23, 2015 at 8:51 AM, Kevin Benton <blak111 at gmail.com> wrote:
>>>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.
>
>+1.  That's where I was going.

Agreed, this seems reasonable to me for the migration scheduling case.

I view the pre-created port scenario as an edge case.  By explicitly
pre-creating a port and using it for a new instance (rather than letting
nova create a port for you), you are implicitly stating that you have more
knowledge about the networking setup.  In so doing, you’re removing the
guard rails (of nova scheduling the instance to a good network for the
host it's on), and therefore are at higher risk to crash and burn.  To me
that’s an acceptable trade-off.

Mike

__________________________________________________________________________
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