[openstack-dev] [heat] metadata for a HOT

Clint Byrum clint at fewbar.com
Thu Apr 3 17:10:30 UTC 2014


Excerpts from Mike Spreitzer's message of 2014-04-02 22:10:21 -0700:
> Zane Bitter <zbitter at redhat.com> wrote on 04/02/2014 05:36:43 PM:
> 
> > I think that if you're going to propose a new feature, you should at 
> > least give us a clue who you think is going to use it and what for ;)
> 
> I was not eager to do that yet because I have not found a fully 
> satisfactory answer yet, at this point I am exploring options.  But the 
> problem I am thinking about is how Heat might connect to a holistic 
> scheduler (a scheduler that makes a joint decision about a bunch of 
> resources of various types).  Such a scheduler needs input describing the 
> things to be scheduled and the policies to apply in scheduling; the first 
> half of that sounds a lot like a Heat template, so my thoughts go in that 
> direction.  But the HOT language today (since 
> https://review.openstack.org/#/c/83758/ was merged) does not have a place 
> to put policy that is not specific to a single resource.
> 

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.

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.

> > IIRC this has been discussed in the past and the justifications for 
> > including it in the template (as opposed to allowing metadata to be 
> > attached in the ReST API, as other projects already do for many things) 
> > were not compelling.
> 
> I see that Keith Bray mentioned 
> https://wiki.openstack.org/wiki/Heat/StackMetadata and 
> https://wiki.openstack.org/wiki/Heat/UI in another reply on this thread. 
> Are there additional places to look to find that discussion?
> 
> I have also heard that there has been discussion of language extension 
> issues.  Is that a separate discussion and, if so, where can I read it?

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.

I think the way hot-software-config has taken shape is a prime example
of this. We took the most common patterns and made a set of resources
that encapsulate them. But we didn't have to extend the language any. It
is all done in resources. (Kudos to Steve Baker for getting it done btw,
this was _not_ a small amount of work).



More information about the OpenStack-dev mailing list