Open Stack

Zane Bitter <zbitter at redhat.com> wrote on 07/10/2014 05:57:14 PM:

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

If we're whittling down then it would be one or more AZs, right?

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

I am not sure I understand what you mean.  Is it: "there is no way for the 
implementation of a resource type to create or modify an intrinsic 
function"?

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

I am not sure I get this part.  If the scaling group member type is a 
Compute instance (as well as if it is not) then the template generated by 
the group (to implement the group) wants to put different resources in 
different AZs.  The nested stack that is the scaling group is given a 
whole list of AZs as its list-of-AZs parameter value.

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

I partially get the suggestion.  Let me repeat it back to see if it sounds 
right.
Let the stack create and update operations gain an optional parameter that 
is a list of AZs,
(noting that a stack operation parameter is something different from a 
parameter
specified in a template)
constrained to be a subset of the AZs available to the user in Heat's 
configured region;
the default value is the list of all AZs available to the user in Heat's 
configured region.
Redefine the Fn::GetAZs intrinsic to return that new parameter's value.
For each resource type that can be given a list of AZs, we (as plugin 
authors) redefine the default to be the list returned by Fn::GetAZs;
for each resource type that can be given a single AZ, we (as plugin 
authors) redefine the default to be one (which one?) of the AZs returned 
by Fn::GetAZs.
That would probably require some finessing around the schema technology, 
because a parameter's default value is fixed when the resource type is 
registered, right?
A template generated by scaling group code somehow uses that new stack 
operation parameter
to set the member's AZ when the member is a stack and the scaling group is 
spanning AZs.
Would the new stack operation parameter (list of AZs) be reflected as a 
property of OS::Heat::Stack?
How would that list be passed in a scenario like 
https://review.openstack.org/#/c/97366/10/hot/asg_of_stacks.yaml,unified
where the member type is a template filename and the member's properties 
are simply the stack's parameters?
Can the redefinitions mentioned here be a backward compatibility problem?

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

Well, at least declaring the parameter is something explicit.  If you want 
to call out its special treatment even more clearly, we could add some 
sort of thing that can appear in the schema to indicate the special 
treatment; I am not sure that much work is worth the trouble in this case.

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

Now that you mention it, I see that when the AWS-style scaling groups 
(once ours reach AWS parity in this matter) implicitly add an AZ parameter 
when they create a member from a LaunchConfig.  This makes me more 
comfortable with doing the analogous thing in the Heat-native scaling 
groups.  This only leaves discomfort with associating semantics with 
names.  Maybe adding something to the schema language is the way to finish 
this off.

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

In that future, how will the members of a native scaling group be 
specified?  I would expect it would be with a Heat resource type and 
property values.  If that's the case, then the scaling group can still 
validate that the member can be given an AZ parameter, right?

Thanks,
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140711/ff82b79b/attachment.html>