Open Stack

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.

Mike