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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
