|
|
Line 1: |
Line 1: |
− | = Summary =
| |
− | This is a proposal for an additional field, "keywords", to be added to the HOT specification. This field will contain a list of keywords related to the template that generally describe the purpose of the template.
| |
| | | |
− |
| |
− | = Use Case =
| |
− | 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.
| |
− |
| |
− |
| |
− | = Specification =
| |
− | keywords: [wordpress, mysql, lamp]
| |