<tt><font size=2>Keith Bray <keith.bray@RACKSPACE.COM> wrote on
04/03/2014 01:50:28 PM:<br>
<br>
> We proposed another specific piece of template data [3] which I <br>
> can't remember whether it was met with resistance or we just didn't
<br>
> get to implementing it since we knew we would have to store other
<br>
> data specific to our uses cases in other files anyway.   We decided
<br>
> to go with storing our extra information in a catalog (really just
a<br>
> Git repo with a README.MD [4]) for now  until we can implement
<br>
> acceptable catalog functionality somewhere like Glance, hopefully
in<br>
> the Juno cycle.  When we want to share the template, we share
all <br>
> the files in the repo (inclusive of the README.MD).  It would
be <br>
> more ideal if we could share a single file (package) inclusive of
<br>
> the template and corresponding help text and any other UI hint info
<br>
> that would helpful.  I expect service providers to have differing
<br>
> views of the extra data they want to store with a template... So <br>
> it'd just be nice to have a way to account for service providers to
<br>
> store their unique data along with a template that is easy to share
<br>
> and is part of the template package.  We bring up portability
and <br>
> structured data often, but I'm starting to realize that portability
<br>
> of a template breaks down unless every service provider runs exactly<br>
> the same Heat resources, same image IDs, flavor types, etc.). I'd
<br>
> like to drive more standardization of data for image and template
<br>
> data into Glance so that in HOT we can just declare things like <br>
> "Linux, Flavor Ubuntu, latest LTS, minimum 1Gig" and automatically
<br>
> discover and choose the right image to provision, or error if a <br>
> suitable match can not be found.  The Murano team has been hinting
<br>
> at wanting to solve a similar problem, but with a broader vision <br>
> from a complex-multi application declaration perspective that <br>
> crosses multiple templates or is a layer above just matching to what<br>
> capabilities Heat resources provide and matching against <br>
> capabilities that a catalog of templates provide (and mix that with
<br>
> capabilities the cloud API services provide).  I'm not yet convinced<br>
> that can't be done with a parent Heat template since we already have<br>
> the declarative constructs and language well defined, but I <br>
> appreciate the use case and perspective those folks are bringing to
<br>
> the conversation.</font></tt>
<br>
<br><tt><font size=2>Keith, thanks for the background and wider context.
 I am responding directly on my original point elsewhere, but let
me pick up on a couple of things you mentioned in your wider context.  I
definitely see a reason for interest in packaging something bigger than
a single template.  As one very simple example, I have been exercising
OS::Heat::AutoScalingGroup with a pair of templates (an outer template
in which the ASG is a resource, where the element being scaled is a nested
stack, prescribed by the other template in my package).  Since we
are so fond here of solving problems with nested templates, I think there
will be an increasing need to package together not only templates but also
environment snippets (and, yeah, we need to smooth out how the receiver
combines environment snippets).</font></tt>
<br>
<br><tt><font size=2>I agree that template portability is problematic due
to the non-portability of image UUIDs and flavors.  The approach you
pointed towards looks attractive, but it is challenging to enable a template
author to write a specification that is not too precise and not too liberal
--- particularly since the template author has a hard time anticipating
the creativity with which the receiving environment is populated.  I
assume this has been extensively discussed already.  If not I may
make some noise later.</font></tt>
<br>
<br><tt><font size=2>Thanks,</font></tt>
<br><tt><font size=2>Mike</font></tt>