Open Stack

Zane Bitter <zbitter at redhat.com> wrote on 07/01/2014 06:54:58 PM:

> On 01/07/14 16:23, Mike Spreitzer wrote:
> > An AWS autoscaling group can span multiple availability zones in one
> > region.  What is the thinking about how to get analogous functionality
> > in OpenStack?
> ...
> > 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.
> 
> The concept of an availability zone for a stack is not meaningful. 
> Servers have availability zones; stacks exist in one region. It is up to 

> the *operator*, not the user, to deploy Heat in such a way that it 
> remains highly-available assuming the Region is still up.

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.

> So yes, the tricky part is how to handle that when the scaling unit is 
> not a server (or a provider template with the same interface as a 
server).
> 
> One solution would have been to require that the scaled unit was, 
> indeed, either an OS::Nova::Server or a provider template with the same 
> interface as (or a superset of) an OS::Nova::Server, but the consensus 
> was against that. (Another odd consequence of this decision is that 
> we'll potentially be overwriting an AZ specified in the "launch config" 
> section with one from the list supplied to the scaling group itself.)
> 
> For provider templates, we could insert a pseudo-parameter containing 
> the availability zone. I think that could be marginally better than 
> taking over one of the user's parameters, but you're basically on the 
> right track IMO.

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.

> Unfortunately, that is not the end of the story, because we still have 
> to deal with other types of resources being scaled. I always advocated 
> for an autoscaling resource where the scaled unit was either a provider 
> stack (if you provided a template) or an OS::Nova::Server (if you 
> didn't), but the implementation that landed followed the design of 
> ResourceGroup by allowing (actually, requiring) you to specify an 
> arbitrary resource type.
> 
> We could do something fancy here involving tagging the properties schema 

> with metadata so that we could allow plugin authors to map the AZ list 
> to an arbitrary property. However, I propose that we just raise a 
> validation error if the AZ is specified for a resource that is not 
> either an OS::Nova::Server or a provider template.

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.

I just reviewed LaunchConfiguration (
http://docs.openstack.org/developer/heat/template_guide/cfn.html#AWS::AutoScaling::LaunchConfiguration
) and noticed that it does not have an availability_zone.

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).

I submitted the first draft of a spec along these lines.

Thanks,
Mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140709/712a7619/attachment.html>