Open Stack

On 11/27/13 4:12 PM, "Steve Baker" <sbaker at redhat.com> wrote:

>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:
>https://www.dropbox.com/s/43imlv2l9nfsj9e/Screenshot%20from%202013-11-28%2
>011%3A05%3A43.png
>
>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
>description.)
>
>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.

+1 Yes, this is a great illustration of how I would expect the 2 fields to
be used.

Thanks Steve!
Tim
>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev