<tt><font size=2>Zane Bitter <zbitter@redhat.com> wrote on 07/10/2014
05:57:14 PM:<br>
<br>
> On 09/07/14 22:38, Mike Spreitzer wrote:<br>
> > 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>
...<br>
> <br>
> Hmm, now that I think about it, CloudFormation provides a Fn::GetAZs
<br>
> function that returns a list of available AZs. That suggests an <br>
> implementation where you can specify an AZ</font></tt>
<br>
<br><tt><font size=2>If we're whittling down then it would be one or more
AZs, right?</font></tt>
<br>
<br><tt><font size=2>>              
                     
       when creating the stack and <br>
> the function returns only that value within that stack (and its <br>
> children). There's no way in OS::Heat::AutoScalingGroup to specify
an <br>
> intrinsic function that is resolved in the context of the scaling
<br>
> group's nested stack,</font></tt>
<br>
<br><tt><font size=2>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"?</font></tt>
<br>
<br><tt><font size=2>>              
        but if the default value of the AZ for <br>
> OS::Nova::Server were calculated the same way then the user would
have <br>
> the option of omitting the AZ (to allow the autoscaling implementation
<br>
> to control it)</font></tt>
<br>
<br><tt><font size=2>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.</font></tt>
<br>
<br><tt><font size=2>>              
 or overriding it explicitly. At that point you don't even <br>
> need the intrinsic function.<br>
> <br>
> So don't assign a stack to a particular AZ as such, but allow the
list <br>
> of valid AZs to be whittled down as you move toward the leaves of
the <br>
> tree of templates.</font></tt>
<br>
<br><tt><font size=2>I partially get the suggestion.  Let me repeat
it back to see if it sounds right.</font></tt>
<br><tt><font size=2>Let the stack create and update operations gain an
optional parameter that is a list of AZs,</font></tt>
<br><tt><font size=2>(noting that a stack operation parameter is something
different from a parameter</font></tt>
<br><tt><font size=2>specified in a template)</font></tt>
<br><tt><font size=2>constrained to be a subset of the AZs available to
the user in Heat's configured region;</font></tt>
<br><tt><font size=2>the default value is the list of all AZs available
to the user in Heat's configured region.</font></tt>
<br><tt><font size=2>Redefine the Fn::GetAZs intrinsic to return that new
parameter's value.</font></tt>
<br><tt><font size=2>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;</font></tt>
<br><tt><font size=2>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.</font></tt>
<br><tt><font size=2>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?</font></tt>
<br><tt><font size=2>A template generated by scaling group code somehow
uses that new stack operation parameter</font></tt>
<br><tt><font size=2>to set the member's AZ when the member is a stack
and the scaling group is spanning AZs.</font></tt>
<br><tt><font size=2>Would the new stack operation parameter (list of AZs)
be reflected as a property of OS::Heat::Stack?</font></tt>
<br><tt><font size=2>How would that list be passed in a scenario like </font></tt><a href="https://review.openstack.org/#/c/97366/10/hot/asg_of_stacks.yaml,unified"><tt><font size=2>https://review.openstack.org/#/c/97366/10/hot/asg_of_stacks.yaml,unified</font></tt></a>
<br><tt><font size=2>where the member type is a template filename and the
member's properties are simply the stack's parameters?<br>
Can the redefinitions mentioned here be a backward compatibility problem?</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<br>
> > 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.<br>
> ><br>
> > I considered a built-in function or pseudo parameter and rejected
them<br>
> > based on a design principle that was articulated in an earlier<br>
> > discussion: "no modes".  Making the innermost
template explicitly<br>
> > declare that it takes an AZ parameter makes it more explicit
what is<br>
> > going on.  But I agree that this is a relatively minor design
point, and<br>
> > would be content to go with a pseudo-parameter if the community
really<br>
> > 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>
> ><br>
> > Yes, I agree with limiting ambition.  For OS::Heat::AutoScalingGroup
and<br>
> > ResourceGroup, I think a pretty simple rule will cover all the
cases<br>
> > that matter besides nested stack: if the member resource type
has a<br>
> > string parameter named "availability zone" (camel or
snake case) then<br>
> > this is valid.<br>
> <br>
> I don't love the idea of inferring the semantics of parameters from
<br>
> their names. "No modes" can be a useful design heuristic
(Disclaimer: <br>
> vim user), but so can "explicit is better than implicit".</font></tt>
<br>
<br><tt><font size=2>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.<br>
<br>
> > I just reviewed LaunchConfiguration<br>
> > (</font></tt><a href=http://docs.openstack.org/developer/heat/template_guide/><tt><font size=2>http://docs.openstack.org/developer/heat/template_guide/</font></tt></a><tt><font size=2><br>
> cfn.html#AWS::AutoScaling::LaunchConfiguration)<br>
> > and noticed that it does not have an availability_zone.<br>
> <br>
> Yes, because the AZ is determined by the autoscaling group's algorithm.
<br>
> This is the advantage of requiring a launch config definition that
is <br>
> not identical to the definition of the scaling unit (the disadvantage
is <br>
> obviously an extreme lack of flexibility).</font></tt>
<br>
<br><tt><font size=2>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.<br>
<br>
> > Since AWS::AutoScalingGroup and OS::Heat::InstanceGroup actually
scale a<br>
> > member type that is mapped to something else in the environment,
these<br>
> > too have the possibility of an actual member type that is not
a Compute<br>
> > instance.  I am hoping that in validation we can check that
the actual<br>
> > member type has an availability zone parameter (camel or snake
case).<br>
> <br>
> I think that should be possible for now, but I don't think it will
be <br>
> when Autoscaling lives in its own process with its own ReST API. Ideally
<br>
> I'd like to plan for that future.</font></tt>
<br>
<br><tt><font size=2>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?<br>
</font></tt>
<br><tt><font size=2>Thanks,</font></tt>
<br><tt><font size=2>Mike</font></tt>
<br>