Open Stack

On 04/02/2014 08:41 PM, Keith Bray wrote:
> https://wiki.openstack.org/wiki/Heat/StackMetadata
>
> https://wiki.openstack.org/wiki/Heat/UI
>
> -Keith
>
Keith,

Taking a look at the UI specification, I thought I'd take a look at 
adding parameter grouping and ordering to the hot_spec.rst file. That 
seems like a really nice constrained use case with a clear way to 
validate that folks aren't adding magic to the template for their custom 
environments.  During that, I noticed it is is already implemented.

What is nice about this specific use case is it is something that can be 
validated by the parser.  For example, the parser could enforce that 
parameters in the parameter-groups section actually exist as parameters 
in the parameters section.  Essentially this particular use case 
*enforces* good heat template implementation without an opportunity for 
HOT template developers to jam customized data blobs into the template.

Stack keywords on the other hand doesn't necessarily follow this model.  
I understand the use case, but it would be possible to jam unstructured 
metadata into the template.  That said, the limitations on the jamming 
custom metadata are one deep and it has a clear use case (categorization 
of templates for support/UI rendering purposes).

I could be wrong, but I think the aversion to a general metadata section 
is centered around the problem of different people doing different 
things in a non-standardized way.

I think if we were to revisit the metadata proposal, one thing that 
might lead to a more successful outcome is actually defining what goes 
in the metadata, rather then allowing the metadata to be completely 
free-form as the HOT developer sees fit to implement it.

For example just taking the keywords proposal:
metadata:
   composed_of:
   - wordpress
   - mysql
   architecture:
   - lamp

Even though this metadata can't necessarily be validated, it can be 
documented.  I definitely have a -2 aversion to free-form metadata 
structuring, and am +0 on allowing the information to be declared in a 
non-validated way.

I don't believe the idea of structured metadata based upon real use 
cases has really been explored or -2'ed.

Regards,
-steve

> From: Lingxian Kong <anlin.kong at gmail.com <mailto:anlin.kong at gmail.com>>
> Reply-To: "OpenStack Development Mailing List (not for usage 
> questions)" <openstack-dev at lists.openstack.org 
> <mailto:openstack-dev at lists.openstack.org>>
> Date: Wednesday, April 2, 2014 9:31 PM
> To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev at lists.openstack.org 
> <mailto:openstack-dev at lists.openstack.org>>
> Subject: Re: [openstack-dev] [heat] metadata for a HOT
>
>     Is there any relevant wiki or specification doc?
>
>
>     2014-04-03 4:45 GMT+08:00 Mike Spreitzer <mspreitz at us.ibm.com
>     <mailto:mspreitz at us.ibm.com>>:
>
>         I would like to suggest that a metadata section be allowed at
>         the top level of a HOT.  Note that while resources in a stack
>         can have metadata, there is no way to put metadata on a stack
>         itself.  What do you think?
>
>         Thanks,
>         Mike
>         _______________________________________________
>         OpenStack-dev mailing list
>         OpenStack-dev at lists.openstack.org
>         <mailto:OpenStack-dev at lists.openstack.org>
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>     -- 
>     *---------------------------------------*
>     *Lingxian Kong*
>     Huawei Technologies Co.,LTD.
>     IT Product Line CloudOS PDU
>     China, Xi'an
>     Mobile: +86-18602962792
>     Email: konglingxian at huawei.com <mailto:konglingxian at huawei.com>;
>     anlin.kong at gmail.com <mailto:anlin.kong at gmail.com>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140403/2f273eb8/attachment.html>