Open Stack

Clint Byrum <clint at fewbar.com> wrote on 04/03/2014 01:10:30 PM:

> Things that affect the stack as a whole really belong in the stack
> API. That would also put them in the OS::Heat::Stack resource, so the
> template language already supports that.

The OS::Heat::Stack resource is one of several that create nested stacks;
we should be able to apply holistic scheduling to all stacks, regardless
of whether they are nest or which kind of nested stack they are.
Yes, if holistic scheduling were a feature in the Heat API then all kinds 
of
resources that create nested stacks "should" expose that feature
(shout out to Trove, autoscaling groups, ...).

> As for policies which might affect a holistic scheduler, those can just
> be resources as well. Just like deployments relate to servers, resources
> can relate to any policies they need.

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?

> I would prefer that we focus on making HOT composable rather than
> extensible. If there is actually something missing from the root of the
> language, then it should be in the language. Use cases should almost
> always try to find a way to work as resources first, and then if that
> is unwieldy, look into language enhancements to factor things out.

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?

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