Open Stack

On 11/26/13 5:24 PM, "Angus Salkeld" <asalkeld at redhat.com> wrote:

>On 26/11/13 22:55 +0000, Tim Schnell wrote:
>>
>>On Tue, Nov 26, 2013 at 4:35 PM, Tim Schnell
>><tim.schnell at rackspace.com<mailto:tim.schnell at rackspace.com>> wrote:
>>
>>From: Christopher Armstrong
>><chris.armstrong at rackspace.com<mailto:chris.armstrong at rackspace.com>>
>>
>>Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>><openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.o
>>rg>>
>>Date: Tuesday, November 26, 2013 4:02 PM
>>
>>To: "OpenStack Development Mailing List (not for usage questions)"
>><openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.o
>>rg>>
>>Subject: Re: [openstack-dev] [heat][horizon]Heat UI related requirements
>>& roadmap
>>
>>On Tue, Nov 26, 2013 at 3:24 PM, Tim Schnell
>><tim.schnell at rackspace.com<mailto:tim.schnell at rackspace.com>> wrote:
>>So the originally question that I attempted to pose was, "Can we add a
>>schema-less metadata section to the template that can be used for a
>>variety of purposes?". It looks like the answer is no, we need to discuss
>>the features that would go in the metadata section and add them to the
>>HOT
>>specification if they are viable. I don't necessarily agree with this
>>answer but I accept it as viable and take responsibility for the
>>long-winded process that it took to get to this point.
>>
>>I think some valid points have been made and I have re-focused my efforts
>>into the following proposed solution.
>>
>>I am fine with getting rid of the concept of a schema-less metadata
>>section. If we can arrive at a workable design for a few use cases then I
>>think that we won't need to discuss any of the options that Zane
>>mentioned
>>for handling the metadata section, comments, separate file, or in the
>>template body.
>>
>>Use Case #1
>>I see valid value in being able to group templates based on a type or
>>keyword. This would allow any client, Horizon or a Template Catalog
>>service, to better organize and handle display options for an end-user.
>>
>>I believe that Ladislav initially proposed a solution that will work
>>here.
>>So I will second a proposal that we add a new top-level field to the HOT
>>specification called "keywords" that contains this template type.
>>
>>        keywords: wordpress, mysql, etc
>>
>>
>>
>>My immediate inclination would be to just make keywords/tags out-of-band
>>metadata managed by the template repository. I imagine this would be
>>something that would be very useful to change without having to edit the
>>template anyway.
>>
>>I'm not exactly sure what you are suggesting here, but I think that
>>adding these keywords to the template will be less error prone than
>>attempting to derive them some other way.
>>
>>
>>Basically, I'm just suggesting putting the tags outside of template. Not
>>deriving them -- I still think they should be explicitly specified, but
>>just putting them in e.g. the database instead of directly in the
>>template.
>>
>>Basically, in a public repository of templates, I can imagine tags being
>>based on third-party or moderator input, instead of just based on what
>>the template author says.  Keeping them outside of the template would
>>allow content moderators to do that without posting a new version of the
>>template.
>>
>>Anyway, I don't feel that strongly about this - if there's a strong
>>enough desire to see tags in the template, then I won't argue against it.
>>---
>>
>>The primary reason I would like to see this live inside of the template
>>is because these keywords should be tied to the current state of the
>>template that is saved by Heat on Stack Create and Stack Update. If
>>someone performs a Stack Update that changes the content of the
>>template, they should be responsible for updating the keywords in the
>>template. If the keywords live outside of the template, it will be
>>difficult to keep them in sync with the actual content of the template.
>>
>>I guess what I'm saying is that the keywords should follow the
>>instantiation of the template which could morph into something that may
>>not match the original keywords that may be saved into a database of
>>templates somewhere.
>
>You have moved into a different use case now:
>"I want a mechanism to tag particular versions of templates"
>
>
>I'd suggest your heat-template-tag does something like this:
>
>hash=$(git hash-object <template>)
>store_tag <template> $hash <new tag name>
>
>then you can query if a template has a particular tag by hashing
>the given template and looking the tags by hash.
>
>So you could have a tag that is "supported", that will be impossible
>to fake. I don't see how you are going to do that by inserting
>metadata into the template (a user could do that too).
>
>-Angus

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.

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