On 26/11/13 22:55 +0000, Tim Schnell wrote:
On Tue, Nov 26, 2013 at 4:35 PM, Tim Schnell 
<tim.schn...@rackspace.com<mailto:tim.schn...@rackspace.com>> wrote:

From: Christopher Armstrong 
<chris.armstr...@rackspace.com<mailto:chris.armstr...@rackspace.com>>

Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, November 26, 2013 4:02 PM

To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [heat][horizon]Heat UI related requirements & 
roadmap

On Tue, Nov 26, 2013 at 3:24 PM, Tim Schnell 
<tim.schn...@rackspace.com<mailto:tim.schn...@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

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

Reply via email to