Open Stack

An AWS autoscaling group can span multiple availability zones in one 
region.  What is the thinking about how to get analogous functionality in 
OpenStack?

Warmup question: what is the thinking about how to get the levels of 
isolation seen between AWS regions when using OpenStack?  What is the 
thinking about how to get the level of isolation seen between AWS AZs in 
the same AWS Region when using OpenStack?  Do we use OpenStack Region and 
AZ, respectively?  Do we believe that OpenStack AZs can really be as 
independent as we want them (note that this is phrased to not assume we 
only want as much isolation as AWS provides --- they have had high profile 
outages due to lack of isolation between AZs in a region)?

I am going to assume that the answer to the question about ASG spanning 
involves spanning OpenStack regions and/or AZs.  In the case of spanning 
AZs, Heat has already got one critical piece: the OS::Heat::InstanceGroup 
and AWS::AutoScaling::AutoScalingGroup types of resources take a list of 
AZs as an optional parameter.  Presumably all four kinds of scaling group 
(i.e., also OS::Heat::AutoScalingGroup and OS::Heat::ResourceGroup) should 
have such a parameter.  We would need to change the code that generates 
the template for the nested stack that is the group, so that it spreads 
the members across the AZs in a way that is as balanced as is possible at 
the time.

Currently, a stack does not have an AZ.  That makes the case of an 
OS::Heat::AutoScalingGroup whose members are nested stacks interesting --- 
how does one of those nested stacks get into the right AZ?  And what does 
that mean, anyway?  The meaning would have to be left up to the template 
author.  But he needs something he can write in his member template to 
reference the desired AZ for the member stack.  I suppose we could 
stipulate that if the member template has a parameter named 
"availability_zone" and typed "string" then the scaling group takes care 
of providing the right value to that parameter.

To spread across regions adds two things.  First, all four kinds of 
scaling group would need the option to be given a list of regions instead 
of a list of AZs.  More likely, a list of contexts as defined in 
https://review.openstack.org/#/c/53313/ --- that would make this handle 
multi-cloud as well as multi-region.  The other thing this adds is a 
concern for context health.  It is not enough to ask Ceilometer to monitor 
member health --- in multi-region or multi-cloud you also have to worry 
about the possibility that Ceilometer itself goes away.  It would have to 
be the scaling group's responsibility to monitor for context health, and 
react properly to failure of a whole context.

Does this sound about right?  If so, I could draft a spec.

Thanks,
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140701/38bef14f/attachment.html>