----- Original Message ----- > > On 7/23/15, 9:42 AM, "Carl Baldwin" <c...@ecbaldwin.net> wrote: > > >On Wed, Jul 22, 2015 at 3:21 PM, Kevin Benton <blak...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev