[openstack-dev] [Neutron][L3] Representing a networks connected by routers
amuller at redhat.com
Mon Jul 27 14:25:40 UTC 2015
----- Original Message -----
> On 7/23/15, 9:42 AM, "Carl Baldwin" <carl at ecbaldwin.net> wrote:
> >On Wed, Jul 22, 2015 at 3:21 PM, Kevin Benton <blak111 at gmail.com> wrote:
> >> The issue with the availability zone solution is that we now force
> >> availability zones in Nova to be constrained to network configuration.
> >> the L3 ToR/no overlay configuration, this means every rack is its own
> >> availability zone. This is pretty annoying for users to deal with
> >> they have to choose from potentially hundreds of availability zones and
> >> rules out making AZs based on other things (e.g. current phase, cooling
> >> systems, etc).
> >> I may be misunderstanding and you could be suggesting to not expose this
> >> availability zone to the end user and only make it available to the
> >> scheduler. However, this defeats one of the purposes of availability
> >> which is to let users select different AZs to spread their instances
> >> failure domains.
> >I was actually talking with some guys at dinner during the Nova
> >mid-cycle last night (Andrew ??, Robert Collins, Dan Smith, probably
> >others I can't remember) about the relationship of these network
> >segments to AZs and cells. I think we were all in agreement that we
> >can't confine segments to AZs or cells nor the other way around.
> I just want to +1 this one from the operators’ perspective. Network
> segments, availability zones, and cells are all separate constructs which
> are used for different purposes. We prefer to not have any relationships
> forced between them.
I agree, which is why I later corrected to expose physical_networks details
via the API instead, and feed that info to the Nova scheduler.
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev