On Wed, Jul 22, 2015 at 3:21 PM, Kevin Benton <[email protected]> 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. Carl __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
