On 11/27/13 4:12 PM, "Steve Baker" <sba...@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@lists.openstack.org >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev