Open Stack

----- 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.
> >>In
> >> the L3 ToR/no overlay configuration, this means every rack is its own
> >> availability zone. This is pretty annoying for users to deal with
> >>because
> >> they have to choose from potentially hundreds of availability zones and
> >>it
> >> 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
> >>zones
> >> which is to let users select different AZs to spread their instances
> >>across
> >> 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.

> 
> 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
>