Open Stack

Excerpts from Tim Schnell's message of 2013-11-25 14:51:39 -0800:
> Hi Steve,
> 
> As one of the UI developers driving the requirements behind these new
> blueprints I wanted to take a moment to assure you and the rest of the
> Openstack community that the primary purpose of pushing these requirements
> out to the community is to help improve the User Experience for Heat for
> everyone. Every major UI feature that I have implemented for Heat has been
> included in Horizon, see the Heat Topology, and these requirements should
> improve the value of Heat, regardless of the UI.
> 
> 
> Stack/template metadata
> We have a fundamental need to have the ability to reference some
> additional metadata about a template that Heat does not care about. There
> are many possible use cases for this need but the primary point is that we
> need a place in the template where we can iterate on the schema of the
> metadata without going through a lengthy design review. As far as I know,
> we are the only team attempting to actually productize Heat at the moment
> and this means that we are encountering requirements and requests that do
> not affect Heat directly but simply require Heat to allow a little wiggle
> room to flesh out a great user experience.
> 

Wiggle room is indeed provided. But reviewers need to understand your
motivations, which is usually what blueprints are used for. If you're
getting push back, it is likely because your blueprints to not make the
use cases and long term vision obvious.

> There is precedence for an optional metadata section that can contain any
> end-user data in other Openstack projects and it is necessary in order to
> iterate quickly and provide value to Heat.
> 

Nobody has said you can't have meta-data on stacks, which is what other
projects use.

> There are many use cases that can be discussed here, but I wanted to
> reiterate an initial discussion point that, by definition,
> "stack/template_metadata" does not have any hard requirements in terms of
> schema or what does or does not belong in it.
> 
> One of the initial use cases is to allow template authors to categorize
> the template as a specific "type".
> 
>     template_metadata:
>         short_description: Wordpress
> 
>     

Interesting. Would you support adding a "category" keyword to python so
we don't have to put it in setup.cfg and so that the egg format doesn't
need that section? Pypi can just parse the python to categorize the apps
when they're uploaded. We could also have a file on disk for qcow2 images
that we upload to glance that will define the meta-data.

To be more direct, I don't think the templates themselves are where this
meta-data belongs. A template is self-aware by definition, it doesn't
need the global metadata section to tell it that it is WordPress. For
anything else that needs to be globally referenced there are parameters.
Having less defined inside the template means that you get _more_ wiggle
room for your template repository.

I 100% support having a template catalog. IMO it should be glance,
which is our catalog service in OpenStack. Who cares if nova or heat are
consuming images or templates. It is just sharable blobs of data and
meta-data in a highly scalable service. It already has the concept of
global and tenant-scope. It just needs an image type of 'hot' and then
heat can start consuming templates from glance. And the template authors
should maintain some packaging meta-data in glance to communicate to
users that this is "Wordpress" and "Single-Node". If Glance's meta-data
is too limiting, expand it! I'm sure image authors and consumers would
appreciate that.

> This would let the client of the Heat API group the templates by type
> which would create a better user experience when selecting or managing
> templates. The the end-user could select "Wordpress" and drill down
> further to select templates with different options, "single node", "2 web
> nodes", etc...
> 

That is all api stuff, not language stuff.

> Once a feature has consistently proven that it adds value to Heat or
> Horizon, then I would suggest that we can discuss the schema for that
> feature and codify it then.
> 
> In order to keep the discussion simple, I am only responding to the need
> for stack/template metadata at the moment but I'm sure discussions on the
> management api and template catalog will follow.
> 

Your example puts the template catalog in front of this feature, and I
think that exposes this feature as misguided.