<tt><font size=2>Zane Bitter <zbitter@redhat.com> wrote on 07/01/2014
06:54:58 PM:<br>
<br>
> On 01/07/14 16:23, Mike Spreitzer wrote:<br>
> > An AWS autoscaling group can span multiple availability zones
in one<br>
> > region.  What is the thinking about how to get analogous
functionality<br>
> > in OpenStack?<br>
> ...<br>
> > Currently, a stack does not have an AZ.  That makes the
case of an<br>
> > OS::Heat::AutoScalingGroup whose members are nested stacks interesting<br>
> > --- how does one of those nested stacks get into the right AZ?
 And what<br>
> > does that mean, anyway?  The meaning would have to be left
up to the<br>
> > template author.  But he needs something he can write in
his member<br>
> > template to reference the desired AZ for the member stack.  I
suppose we<br>
> > could stipulate that if the member template has a parameter named<br>
> > "availability_zone" and typed "string" then
the scaling group takes care<br>
> > of providing the right value to that parameter.<br>
> <br>
> The concept of an availability zone for a stack is not meaningful.
<br>
> Servers have availability zones; stacks exist in one region. It is
up to <br>
> the *operator*, not the user, to deploy Heat in such a way that it
<br>
> remains highly-available assuming the Region is still up.</font></tt>
<br>
<br><tt><font size=2>There are two distinct issues there: (1) making the
heat engine HA and (2) making a scaling group of stacks span across AZs
(within a region).  I agree that (1) is the cloud provider's problem,
and never meant to suggest otherwise.  I think (2) makes sense by
analogy: a nested stack is a way of implementing a particular abstraction
(defined by the template) --- in fact the outer template author might not
even be aware that the group members are stacks, thanks to provider templates
--- and here we suppose the user has chosen to use an abstraction that
makes sense to be considered to be "in" an AZ.  While a
stack in general does not have an AZ, I think we can suppose that if the
outer template author asked for stacks to be spread across AZs then the
stacks in question can reasonably considered to each be in one AZ.  For
example, the inner template might contain a Compute instance and a Cinder
volume and an attachment between the two; such a stack makes sense to put
"in" an AZ.  Heat itself does not even need there to be
any particular real meaning to a stack being "in" an AZ, all
I am proposing is that Heat make this concept available to the authors
of the outer and innermost templates to use in whatever way they find useful.</font></tt>
<br><tt><font size=2><br>
> So yes, the tricky part is how to handle that when the scaling unit
is <br>
> not a server (or a provider template with the same interface as a
server).<br>
> <br>
> One solution would have been to require that the scaled unit was,
<br>
> indeed, either an OS::Nova::Server or a provider template with the
same <br>
> interface as (or a superset of) an OS::Nova::Server, but the consensus
<br>
> was against that. (Another odd consequence of this decision is that
<br>
> we'll potentially be overwriting an AZ specified in the "launch
config" <br>
> section with one from the list supplied to the scaling group itself.)<br>
> <br>
> For provider templates, we could insert a pseudo-parameter containing
<br>
> the availability zone. I think that could be marginally better than
<br>
> taking over one of the user's parameters, but you're basically on
the <br>
> right track IMO.</font></tt>
<br>
<br><tt><font size=2>I considered a built-in function or pseudo parameter
and rejected them based on a design principle that was articulated in an
earlier discussion: "no modes".  Making the innermost template
explicitly declare that it takes an AZ parameter makes it more explicit
what is going on.  But I agree that this is a relatively minor design
point, and would be content to go with a pseudo-parameter if the community
really prefers that.<br>
<br>
> Unfortunately, that is not the end of the story, because we still
have <br>
> to deal with other types of resources being scaled. I always advocated
<br>
> for an autoscaling resource where the scaled unit was either a provider
<br>
> stack (if you provided a template) or an OS::Nova::Server (if you
<br>
> didn't), but the implementation that landed followed the design of
<br>
> ResourceGroup by allowing (actually, requiring) you to specify an
<br>
> arbitrary resource type.<br>
> <br>
> We could do something fancy here involving tagging the properties
schema <br>
> with metadata so that we could allow plugin authors to map the AZ
list <br>
> to an arbitrary property. However, I propose that we just raise a
<br>
> validation error if the AZ is specified for a resource that is not
<br>
> either an OS::Nova::Server or a provider template.<br>
</font></tt>
<br><tt><font size=2>Yes, I agree with limiting ambition.  For OS::Heat::AutoScalingGroup
and ResourceGroup, I think a pretty simple rule will cover all the cases
that matter besides nested stack: if the member resource type has a string
parameter named "availability zone" (camel or snake case) then
this is valid.</font></tt>
<br>
<br><tt><font size=2>I just reviewed LaunchConfiguration (</font></tt><a href=http://docs.openstack.org/developer/heat/template_guide/cfn.html#AWS::AutoScaling::LaunchConfiguration><tt><font size=2>http://docs.openstack.org/developer/heat/template_guide/cfn.html#AWS::AutoScaling::LaunchConfiguration</font></tt></a><tt><font size=2>)
and noticed that it does not have an availability_zone.</font></tt>
<br>
<br><tt><font size=2>Since AWS::AutoScalingGroup and OS::Heat::InstanceGroup
actually scale a member type that is mapped to something else in the environment,
these too have the possibility of an actual member type that is not a Compute
instance.  I am hoping that in validation we can check that the actual
member type has an availability zone parameter (camel or snake case).</font></tt>
<br>
<br><tt><font size=2>I submitted the first draft of a spec along these
lines.</font></tt>
<br>
<br><tt><font size=2>Thanks,</font></tt>
<br><tt><font size=2>Mike</font></tt>
<br>
<br>