You bring up a good point Thomas. I think some of the discussions are mixing template and stack perspectives, they are not the same thing, stack == instance of a template. There likely is room for "tagging" stacks, all under the control of the user and meant for user consumption, vs the long going discussion on template-level metadata. This may be yet another use case ;-)
Edmund Troche Senior Software Engineer
IBM Software Group |
11501 Burnet Rd. |
Austin, TX 78758
( +1.512.286.8977 ) T/L
363.8977 *
edmund.tro...@us.ibm.com
7 +1.512.286.8977
From: Thomas Spatzier <thomas.spatz...@de.ibm.com>
To: "OpenStack Development Mailing List \(not for usage questions
\)" <openstack-dev@lists.openstack.org>,
Date: 11/27/2013 11:00 AM
Subject: Re: [openstack-dev] [heat][horizon]Heat UI related requirements
& roadmap
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
<<inline: graycol.gif>>
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
