Open Stack

On Thu, Apr 3, 2014 at 10:50 AM, Keith Bray <keith.bray at rackspace.com>wrote:

>  Steve, agreed.  Your description I believe is the conclusion that the
> community came to when this was perviously discussed, and we managed to get
> the implementation of parameter grouping and ordering [1] that you
> mentioned which has been very helpful.  I don't think we landed the
> keywords blueprint [2], which may be controversial because it is
> essentially unstructured. I wanted to make sure Mike had the links for
> historical context, but certainly understand and appreciate your point of
> view here.  I wasn't able to find the email threads to point Mike to, but
> assume they exist in the list archives somewhere.
>
>  We proposed another specific piece of template data [3] which I can't
> remember whether it was met with resistance or we just didn't get to
> implementing it since we knew we would have to store other data specific to
> our uses cases in other files anyway.   We decided to go with storing our
> extra information in a catalog (really just a Git repo with a README.MD[4]) for now  until we can implement acceptable catalog functionality
> somewhere like Glance, hopefully in the Juno cycle.  When we want to share
> the template, we share all the files in the repo (inclusive of the
> README.MD).  It would be more ideal if we could share a single file
> (package) inclusive of the template and corresponding help text and any
> other UI hint info that would helpful.  I expect service providers to have
> differing views of the extra data they want to store with a template... So
> it'd just be nice to have a way to account for service providers to store
> their unique data along with a template that is easy to share and is part
> of the template package.  We bring up portability and structured data
> often, but I'm starting to realize that portability of a template breaks
> down unless every service provider runs exactly the same Heat resources,
> same image IDs, flavor types, etc.). I'd like to drive more standardization
> of data for image and template data into Glance so that in HOT we can just
> declare things like "Linux, Flavor Ubuntu, latest LTS, minimum 1Gig" and
> automatically discover and choose the right image to provision, or error if
> a suitable match can not be found.
>

Yes, this is exactly the use case that has been driving our consideration
of the artifacts resource in Glance.

You mentioned discovery of compatible resources. I think its an important
use case, but I think the export and import approach can also be very
useful and I'd like to believe it is the general solution to cloud
portability.


>  The Murano team has been hinting at wanting to solve a similar problem,
> but with a broader vision from a complex-multi application declaration
> perspective that crosses multiple templates or is a layer above just
> matching to what capabilities Heat resources provide and matching against
> capabilities that a catalog of templates provide (and mix that with
> capabilities the cloud API services provide).  I'm not yet convinced that
> can't be done with a parent Heat template since we already have the
> declarative constructs and language well defined, but I appreciate the use
> case and perspective those folks are bringing to the conversation.
>
>  [1]
> https://blueprints.launchpad.net/heat/+spec/parameter-grouping-ordering
>  https://wiki.openstack.org/wiki/Heat/UI#Parameter_Grouping_and_Ordering
>
>  [2] https://blueprints.launchpad.net/heat/+spec/stack-keywords
> https://wiki.openstack.org/wiki/Heat/UI#Stack_Keywords
>
>  [3] https://blueprints.launchpad.net/heat/+spec/add-help-text-to-template
> https://wiki.openstack.org/wiki/Heat/UI#Help_Text
>
>  [4] Ex. Help Text accompanying a template in README.MD format:
> https://github.com/rackspace-orchestration-templates/docker
>
>  -Keith
>
>   From: Steven Dake <sdake at redhat.com>
>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> Date: Thursday, April 3, 2014 10:30 AM
>
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [heat] metadata for a HOT
>
>   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>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> 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>
> 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>:
>
>> 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
>> 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; anlin.kong at gmail.com
>
>
>
> _______________________________________________
> OpenStack-dev mailing listOpenStack-dev at lists.openstack.orghttp://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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140403/6672fb71/attachment.html>