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%2011%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. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
