Thanks, that clarified the use case a bit. Bot looking at the use case now, isn't this stack tagging instead of template tagging? I.e. assume that for each stack a user creates, he/she can assign one or more tags so you can do better queries to find stacks later?
Regards, Thomas Tim Schnell <tim.schn...@rackspace.com> wrote on 27.11.2013 16:24:18: > From: Tim Schnell <tim.schn...@rackspace.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org>, > Date: 27.11.2013 16:28 > Subject: Re: [openstack-dev] [heat][horizon]Heat UI related > requirements & roadmap > > Ok, I just re-read my example and that was a terrible example. I'll try > and create the user story first and hopefully answer Clint's and Thomas's > concerns. > > > If the only use case for adding keywords to the template is to help > organize the template catalog then I would agree the keywords would go > outside of heat. The second purpose for keywords is why I think they > belong in the template so I'll cover that. > > Let's assume that an end-user of Heat has spun up 20 stacks and has now > requested help from a Support Operator of heat. In this case, the end-user > did not have a solid naming convention for naming his stacks, they are all > named "tim1", "tim2", etcŠ And also his request to the Support Operator > was really vague, like "My Wordpress stack is broken." > > The first thing that the Support Operator would do, would be to pull up > end-user's stacks in either Horizon or via the heat client api. In both > cases, at the moment, he would then have to either stack-show on each > stack to look at the description of the stack or ask the end-user for a > stack-id/stack-name. This currently gets the job done but a better > experience would be for stack-list to already display some keywords about > each stack so the Support Operator would have to do less digging. > > In this case the end-user only has one Wordpress stack so he would have > been annoyed if the Support Operator requested more information from him. > (Or maybe he has more than one wordpress stack, but only one currently in > CREATE_FAILED state). > > As a team, we have already encountered this exact situation just doing > team testing so I imagine that others would find value in a consistent way > to determine at least a general purpose of a stack, from the stack-list > page. Putting the stack-description in the stack-list table would take up > too much room from a design standpoint. > > Once keywords has been added to the template then part of the blueprint > would be to return it with the stack-list information. > > The previous example I attempted to explain is really more of an edge > case, so let's ignore it for now. > > Thanks, > Tim > > On 11/27/13 3:19 AM, "Thomas Spatzier" <thomas.spatz...@de.ibm.com> wrote: > > >Excerpts from Tim Schnell's message on 27.11.2013 00:44:04: > >> From: Tim Schnell <tim.schn...@rackspace.com> > >> To: "OpenStack Development Mailing List (not for usage questions)" > >> <openstack-dev@lists.openstack.org>, > >> Date: 27.11.2013 00:47 > >> Subject: Re: [openstack-dev] [heat][horizon]Heat UI related > >> requirements & roadmap > >> > >> > > > ><snip> > > > >> That is not the use case that I'm attempting to make, let me try again. > >> For what it's worth I agree, that in this use case "I want a mechanism > >>to > >> tag particular versions of templates" your solution makes sense and will > >> probably be necessary as the requirements for the template catalog start > >> to become defined. > >> > >> What I am attempting to explain is actually much simpler than that. > >>There > >> are 2 times in a UI that I would be interested in the keywords of the > >> template. When I am initially browsing the catalog to create a new > >>stack, > >> I expect the stacks to be searchable and/or organized by these keywords > >> AND when I am viewing the stack-list page I should be able to sort my > >> existing stacks by keywords. > >> > >> In this second case I am suggesting that the end-user, not the Template > >> Catalog Moderator should have control over the keywords that are defined > >> in his instantiated stack. So if he does a Stack Update, he is not > >> committing a new version of the template back to a git repository, he is > >> just updating the definition of the stack. If the user decides that the > >> original template defined the keyword as "wordpress" and he wants to > >> revise the keyword to "tims wordpress" then he can do that without the > >> original template moderator knowing or caring about it. > >> > >> This could be useful to an end-user who's business is managing client > >> stacks on one account maybe. So he could have "tims wordpress", "tims > >> drupal", "angus wordpress", "angus drupal" the way that he updates the > >> keywords after the stack has been instantiated is up to him. Then he can > >> sort or search his stacks on his own custom keywords. > >> > > > >For me this all sounds like really user specific tagging, so something > >that > >should really be done outside the template file itself in the template > >catalog service. The use case seems about a role that organizes templates > >(or later stacks) by some means, which is fine, but then everything is a > >decision of the person organizing the templates, and not necessarily a > >decision of the template author. So it would be cleaner to keep this > >tagging outside the template IMO. > > > >> I agree that the template versioning is a separate use case. > >> > >> Tim > >> > > >> >> > >> >>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 > >> > >> > >> _______________________________________________ > >> 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 > > > _______________________________________________ > 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
