Yes, I guess you could phrase it as stack tagging, focusing on the template was my attempt to solve 2 use cases with one solution but I'M open to alternatives. Are you suggesting that we build the ability to add "tags" to stacks that exist outside of the template? I guess add them directly to Heat's database?
Tim Schnell Software Developer Rackspace On 11/27/13 10:53 AM, "Thomas Spatzier" <thomas.spatz...@de.ibm.com> wrote: >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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
