Open Stack

Keith Bray <keith.bray at RACKSPACE.COM> wrote on 04/03/2014 01:50:28 PM:

> 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.  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.

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).

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.

Thanks,
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140403/3b0e59ac/attachment.html>