<tt><font size=2>Clint Byrum <clint@fewbar.com> wrote on 04/03/2014
01:10:30 PM:<br>
<br>
> Things that affect the stack as a whole really belong in the stack<br>
> API. That would also put them in the OS::Heat::Stack resource, so
the<br>
> template language already supports that.</font></tt>
<br>
<br><tt><font size=2>The OS::Heat::Stack resource is one of several that
create nested stacks;</font></tt>
<br><tt><font size=2>we should be able to apply holistic scheduling to
all stacks, regardless</font></tt>
<br><tt><font size=2>of whether they are nest or which kind of nested stack
they are.</font></tt>
<br><tt><font size=2>Yes, if holistic scheduling were a feature in the
Heat API then all kinds of</font></tt>
<br><tt><font size=2>resources that create nested stacks "should"
expose that feature</font></tt>
<br><tt><font size=2>(shout out to Trove, autoscaling groups, ...).</font></tt>
<br><tt><font size=2><br>
> As for policies which might affect a holistic scheduler, those can
just<br>
> be resources as well. Just like deployments relate to servers, resources<br>
> can relate to any policies they need.</font></tt>
<br>
<br><tt><font size=2>A holistic scheduler needs input that describes all
the resources to be scheduled as well as all the policies that apply.  Should
a template contain a resource whose input includes a copy of the rest of
the template?</font></tt>
<br><tt><font size=2><br>
> I would prefer that we focus on making HOT composable rather than<br>
> extensible. If there is actually something missing from the root of
the<br>
> language, then it should be in the language. Use cases should almost<br>
> always try to find a way to work as resources first, and then if that<br>
> is unwieldy, look into language enhancements to factor things out.<br>
</font></tt>
<br><tt><font size=2>Yeah, I would too.  Like I said, I have no satisfactory
solution yet.  Here is more of the problem.  I would like to
follow an evolutionary path starting from the instance groups that are
in Nova today.  I think I can outline such an evolution.  I am
sure there will be debate about it.  I am even more sure that it will
take time to accomplish that evolution.  OTOH, locally we have a holistic
scheduler already working.  We want to be able to start using it today.
 What can we do in this interim, and how can we arrange things to
do progressive convergence so that the interim solution evolves as Nova
& scheduling evolve, so that there is no big switch at the end to the
end solution?</font></tt>
<br>
<br><tt><font size=2>Thanks,</font></tt>
<br><tt><font size=2>Mike</font></tt>