Open Stack

Excerpts from Thomas Spatzier's message of 2014-04-03 08:36:20 -0700:
> > From: Mike Spreitzer <mspreitz at us.ibm.com>
> > To: "OpenStack Development Mailing List \(not for usage questions\)"
> > <openstack-dev at lists.openstack.org>
> > Date: 03/04/2014 07:10
> > Subject: Re: [openstack-dev] [heat] metadata for a HOT
> >
> > 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
> singleresource.
> 
> I think you bring up a specific use case here, i.e. applying "policies" for
> placement/scheduling when deploying a stack. This is just a thought, but I
> wonder whether it would make more sense to then define a specific extension
> to HOT instead of having a generic metadata section and stuffing everything
> that does not fit into other places into metadata.
> 

Ever read about Larry "no modes" Tesler? Read up on his arguments
against modes.

I would much prefer any policies to be actual resources which the
resources interact with, rather than template wide modes.

> I mean, the use case Keith brought up are completely different (UI and user
> related), and I understand both use cases. But is the idea to put just
> everything into metadata, or would different classes of use cases justify
> different section? The latter would enforce better documentation of
> semantics. If everyhing goes into a metadata section, the contents also
> need to be clearly specified. Otherwise, the resulting template won't be
> portable. Ok, the standard HOT stuff will be portable, but not the
> metadata, so no two users will be able to interpret it the same way.
>

We had a fairly long debate about keywords and meta-information in HOT
and I thought we came to the conclusion that it belongs in the API and
not in the template language.