On 09/07/14 22:38, Mike Spreitzer wrote:
Zane Bitter <zbit...@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.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
