Open Stack

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.spatzier at 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.schnell at RACKSPACE.COM> wrote on 27.11.2013 16:24:18:
>> From: Tim Schnell <tim.schnell at RACKSPACE.COM>
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev at 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.spatzier at de.ibm.com>
>wrote:
>>
>> >Excerpts from Tim Schnell's message on 27.11.2013 00:44:04:
>> >> From: Tim Schnell <tim.schnell at RACKSPACE.COM>
>> >> To: "OpenStack Development Mailing List (not for usage questions)"
>> >> <openstack-dev at 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 at lists.openstack.org
>> >> >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >> >
>> >> >
>> >> >_______________________________________________
>> >> >OpenStack-dev mailing list
>> >> >OpenStack-dev at lists.openstack.org
>> >> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>
>> >>
>> >> _______________________________________________
>> >> OpenStack-dev mailing list
>> >> OpenStack-dev at lists.openstack.org
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>
>> >
>> >
>> >_______________________________________________
>> >OpenStack-dev mailing list
>> >OpenStack-dev at lists.openstack.org
>> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev