[openstack-dev] [heat][horizon]Heat UI related requirements & roadmap

Steve Baker sbaker at redhat.com
Wed Nov 27 22:12:57 UTC 2013

On 11/28/2013 05:09 AM, Zane Bitter wrote:
> On 26/11/13 22:24, Tim Schnell wrote:
>> Use Case #1
>> I see valid value in being able to group templates based on a type or
> +1, me too.
>> keyword. This would allow any client, Horizon or a Template Catalog
>> service, to better organize and handle display options for an end-user.
> I believe these are separate use cases and deserve to be elaborated as
> such. If one feature can help with both that's great, but we're
> putting the cart before the horse if we jump in and implement the
> feature without knowing why.
> Let's consider first a catalog of operator-provided templates as
> proposed (IIUC) by Keith. It seems clear to me in that instance the
> keywords are a property of the template's position in the catalog, and
> not of the template itself.
> Horizon is a slightly different story. Do we even allow people to
> upload a bunch of templates and store them in Horizon? If not then
> there doesn't seem much point in this feature for current Horizon
> users. (And if we do, which would surprise me greatly, then the
> proposed implementation doesn't seem that practical - would we want to
> retrieve and parse every template to get the keyword?)
> In the longer term, there seems to be a lot of demand for some sort of
> template catalog service, like Glance for templates. (I disagree with
> Clint that it should actually _be_ Glance the project as we know it,
> for the reasons Steve B mentioned earlier, but the concept is right.)
> And this brings us back to a very similar situation to the
> operator-provided template catalog (indeed, that use case would likely
> be subsumed by this one).
>> I believe that Ladislav initially proposed a solution that will work
>> here.
>> So I will second a proposal that we add a new top-level field to the HOT
>> specification called "keywords" that contains this template type.
>>     keywords: wordpress, mysql, etcŠ
> +1. If we decide that the template is the proper place for these tags
> then this is the perfect way to do it IMO (assuming that it's actually
> a list, not a comma-separated string). It's a standard format that we
> can document and any tool can recognise, the name "keywords" describes
> exactly what it does and there's no confusion with "tags" in Nova and
> EC2.
>> Use Case #2
>> The template author should also be able to explicitly define a help
>> string
>> that is distinct and separate from the description of an individual
> This is not a use case, it's a specification. There seems to be a lot
> of confusion about the difference, so let me sum it up:
> Why - Use Case
> What - Specification
> How - Design Document (i.e. Code)
> I know this all sounds very top-down, and believe me that's not my
> philosophy. But design is essentially a global optimisation problem -
> we need to see the whole picture to properly evaluate any given design
> (or, indeed, to find an alternate design), and you're only giving us
> one small piece near the very bottom.
> A use case is something that a user of Heat needs to do.
> An example of a use case would be: The user needs to see two types of
> information in Horizon that are styled differently/shown at different
> times/other (please specify) so that they can ______________________.
> I'm confident that a valid use case _does_ actually exist here, but
> you haven't described it yet.
>> parameter. An example where this use case originated was with Nova
>> Keypairs. The description of a keypair parameter might be something
>> like,
>> "This is the name of a nova key pair that will be used to ssh to the
>> compute instance." A help string for this same parameter would be, "To
>> learn more about nova keypairs click on this help article."
> It's not at all clear to me that these are different pieces of
> information. They both describe the parameter and they're both there
> to help the user. It would be easier to figure out what the right
> thing would be if you gave an example of what you had in mind for how
> Horizon should display these. Even without that, though, it seems to
> me that the help is just adding more detail to the description.
> One idea I suggested in the review comments is to just interpret the
> first paragraph as the description and any subsequent paragraphs as
> the help. There is ample precedent for that kind of interpretation in
> things like Python docstrings and Git commit messages.
Here is a screenshot of a current horizon stack launch form:

Currently the description is used as the field tooltip. The entire right
column isn't really used right now. (I swear it used to show the stack

Anyway, I could imagine showing the parameter description in the
right-hand column when a field gains focus, and the help string being
used for the tooltip instead.

More information about the OpenStack-dev mailing list