<font size=2 face="sans-serif">An AWS autoscaling group can span multiple
availability zones in one region.  What is the thinking about how
to get analogous functionality in OpenStack?</font>
<br>
<br><font size=2 face="sans-serif">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)?</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">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 </font><a href=https://review.openstack.org/#/c/53313/><font size=2 face="sans-serif">https://review.openstack.org/#/c/53313/</font></a><font size=2 face="sans-serif">
--- 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.</font>
<br>
<br><font size=2 face="sans-serif">Does this sound about right?  If
so, I could draft a spec.</font>
<br>
<br><font size=2 face="sans-serif">Thanks,<br>
Mike</font>