Open Stack

I hear you Clint. I'm not an expert on heat templates so it is possible to
do this all with one. However I don't want to use Jinja to replace the heat
template logic just for sane template loading. We are already using Jinja
templates to load custom config files. So it makes sense to re-use the same
loading mechanism to allow administrators to add their own custom heat
templates in a well known location.

I don't want to re-invent the wheel either.

Robert

On Tue, Oct 29, 2013 at 12:24 PM, Clint Byrum <clint at fewbar.com> wrote:

> Excerpts from Robert Myers's message of 2013-10-29 07:54:59 -0700:
> > I'm pulling this conversation out of the gerrit review as I think it
> needs
> > more discussion.
> >
> > https://review.openstack.org/#/c/53499/
> >
>
> After reading the comments in that review, it seems to me that you
> don't need a client side template for your Heat template.
>
> The only argument for templating is "If I want some things to be
> custom I can't have them custom."
>
> You may not realize this, but Heat templates already have basic string
> replacement facilities and mappings, which is _all_ you need here.
>
> Use parameters. Pass _EVERYTHING_ into the stacks you're creating as
> parameters. Then let admins customize using Heat, not _another_
> language.
>
> For instance, somebody brought up wanting to have UserData be
> customizable. It is like this now:
>
> UserData:
>   Fn::Base64:
>     Fn::Join:
>     - ''
>     - ["#!/bin/bash -v\n",
>         "/opt/aws/bin/cfn-init\n",
>         "sudo service trove-guest start\n"]
>
> Since you're using yaml, you don't have to se Fn::Join like in json,
> so simplify to this first:
>
> UserData:
>   Fn::Base64: |
>     #!/bin/bash -v
>     /opt/aws/bin/cfn-init
>     sudo service trove-guest start
>
> Now, the suggestion was that users might want to do a different prep
> per service_type. First, we need to make service_type a parameter
>
>
> Parameters:
>   service_type:
>     Type: String
>     Default: mysql
>
> Now we need to shove it in where needed:
>
> Metadata:
>   AWS::CloudFormation::Init:
>     config:
>       files:
>         /etc/guest_info:
>           content:
>             Fn::Join:
>             - ''
>             - ["[DEFAULT]\nguest_id=", {Ref: InstanceId},
>               "\nservice_type=", {Ref: service_type}, "]"
>           mode: '000644'
>           owner: root
>           group: root
>
> Now, if a user wants to have a different script:
>
> Mappings:
>   ServiceToScript:
>     mysql:
>       script: |
>         #!/bin/bash -v
>         /opt/aws/bin/cfn-init
>         sudo service trove-guest start
>     galera:
>       script: |
>         #!/bin/bash
>         /opt/aws/bin/cfn-init
>         galera-super-thingy
>         sudo service trove-guest start
>
>
> And then they replace the userdata as such:
>
> UserData:
>   Fn::FindInMap:
>     - ServiceToScript
>     - {Ref: service_type}
>     - script
>
> Please can we at least _try_ not to reinvent things!
>
> _______________________________________________
> 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/20131029/8fa0961c/attachment.html>