Open Stack

On 09/07/14 22:38, Mike Spreitzer wrote:
> 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.

Hmm, now that I think about it, CloudFormation provides a Fn::GetAZs 
function that returns a list of available AZs. That suggests an 
implementation where you can specify an AZ when creating the stack and 
the function returns only that value within that stack (and its 
children). There's no way in OS::Heat::AutoScalingGroup to specify an 
intrinsic function that is resolved in the context of the scaling 
group's nested stack, but if the default value of the AZ for 
OS::Nova::Server were calculated the same way then the user would have 
the option of omitting the AZ (to allow the autoscaling implementation 
to control it) or overriding it explicitly. At that point you don't even 
need the intrinsic function.

So don't assign a stack to a particular AZ as such, but allow the list 
of valid AZs to be whittled down as you move toward the leaves of the 
tree of templates.

>  > 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 don't love the idea of inferring the semantics of parameters from 
their names. "No modes" can be a useful design heuristic (Disclaimer: 
vim user), but so can "explicit is better than implicit".

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

Yes, because the AZ is determined by the autoscaling group's algorithm. 
This is the advantage of requiring a launch config definition that is 
not identical to the definition of the scaling unit (the disadvantage is 
obviously an extreme lack of flexibility).

> 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 think that should be possible for now, but I don't think it will be 
when Autoscaling lives in its own process with its own ReST API. Ideally 
I'd like to plan for that future.

cheers,
Zane.