Open Stack

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.

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.

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

    
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...

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.

Thanks,
Tim
@tims on irc






On 11/25/13 12:39 PM, "Steven Hardy" <shardy at redhat.com> wrote:

>All,
>
>So, lately we've been seeing more patches posted proposing added
>functionality to Heat (the API and template syntax) related to
>development of UI functionality.
>
>This makes me both happy (because folks want to use Heat!) and sad
>(because
>it's evident there are several proprietary UI's being developed, rather
>than collaboration focussed on making Horizon Heat functionality great)
>
>One of the most contentious ones currently is that proposing adding
>metadata to the HOT template specification, designed to contain data which
>Heat does not use - my understanding is the primary use-case for this is
>some UI for managing applictions via Heat:
>
>https://review.openstack.org/#/c/56450/
>
>I'd like to attempt to break down some of the communication barriers which
>are increasingly apparent, and refocus our attention on what the actual
>requirements are, and how they relate to improving Heat support in
>Horizon.
>
>The list of things being proposed I can think of are (I'm sure there are
>more):
>- Stack/template metadata
>- Template repository/versioning
>- Management-API functionality (for a Heat service administrator)
>- Exposing build information
>
>I think the template repository and template metadata items are closely
>related - if we can figure out how we expect users to interact with
>multiple versions of templates, access public template repositories,
>attach
>metadata/notes to their template etc in Horizon, then I think much of the
>requirement driving those patches can be satisfied (without necessarily
>implementing that functionality or storing that data in Heat).
>
>For those who've already posted patches and got negative feedback, here's
>my plea - please, please, start communicating the requirements and
>use-cases, then we can discuss the solution together.  Just posting a
>solution with no prior discussion and a minimal blueprint is a really slow
>way to get your required functionality into Heat, and it's frustrating for
>everyone :(
>
>So, lets have a Heat-UI-requirements amnesty, what UI related
>functionality
>do you want in Heat, and why (requirements, use-case/user-story)
>
>Hopefully if we can get these requirements out in the open, it will help
>formulate a roadmap for future improvement of Heat support in Horizon.
>
>Obviously non-Horizon UI users of Heat also directly benefit from this,
>but
>IMO we must focus the discussion primarily on what makes sense for
>Horizon,
>not what makes sense for $veiled_reference_to_internal_project, as the
>wider community don't know anything about the latter, so will naturally
>resist changes related to it.
>
>Steve
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev