Open Stack

Only trove administrator has access to heat templates, user cannot
manipulate templates, if he could we would not need trove at all. And idea
is to store only one template per datastore. And, i know that templates
could be parametrized. But, keep in mind, that we cannot inject in
templates anything (like custom userdata) without modifying project code.
For now there is no need to do this, and i suppose we would not need it
untill some super-custom modifications are needed - userdata is not one of
them.

In trove we have working template which would prepare instance and deliver
code on VM - this is main goal, nothing else.


2013/10/29 Clint Byrum <clint at fewbar.com>

> 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/cb8e14f1/attachment.html>