Open Stack

On 11/27/13 10:58 AM, "Fox, Kevin M" <kevin.fox at pnnl.gov> wrote:


>This use case is sort of a providence case. Where did the stack come from
>so I can find out more about it.
>
>You could put a git commit field in the template itself but then it would
>be hard to keep updated.
>
>How about the following:
>
>Extend heat to support setting a "scmcommit" metadata item on stack
>create. Heat will ignore this but make it available for retrieval.
>
>I'm guessing any catalog will have some sort of scm managing the
>templates. When you go and submit the stack, you can set the metadata and
>know exactly when and where and all the history of the stack by just
>referring to the git commit string.
>
>This should tell you far more then a set of strings a user could set for
>their own use, confusing others.

Hi Kevin,

Yeah I think tying the keywords use case to the template catalog is what
is causing confusion. I agree that the above solution is a good way to
solve this problem for the template catalog. It would definitely be more
specific about what exactly the template represents. But if we remove the
template catalog from the equation and focus on the experience of
providing searchable keywords to the stack either in the template or in
the database. This would solve the use case I'm attempting to describe.

In my use case I'm referring to stacks that are being created with a user
generated template. Something that isn't necessarily a part of any
catalog, in Horizon you can provide a template in a direct input text area
or via file upload.

Tim
>
>Thanks,
>Kevin
>
>________________________________________
>From: Tim Schnell [tim.schnell at RACKSPACE.COM]
>Sent: Wednesday, November 27, 2013 7:24 AM
>To: OpenStack Development Mailing List (not for usage questions)
>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