<div dir="ltr"><div>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.<br>
<br></div>In trove we have working template which would prepare instance and deliver code on VM - this is main goal, nothing else.<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/10/29 Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Robert Myers's message of 2013-10-29 07:54:59 -0700:<br>
<div class="im">> I'm pulling this conversation out of the gerrit review as I think it needs<br>
> more discussion.<br>
><br>
> <a href="https://review.openstack.org/#/c/53499/" target="_blank">https://review.openstack.org/#/c/53499/</a><br>
><br>
<br>
</div>After reading the comments in that review, it seems to me that you<br>
don't need a client side template for your Heat template.<br>
<br>
The only argument for templating is "If I want some things to be<br>
custom I can't have them custom."<br>
<br>
You may not realize this, but Heat templates already have basic string<br>
replacement facilities and mappings, which is _all_ you need here.<br>
<br>
Use parameters. Pass _EVERYTHING_ into the stacks you're creating as<br>
parameters. Then let admins customize using Heat, not _another_<br>
language.<br>
<br>
For instance, somebody brought up wanting to have UserData be<br>
customizable. It is like this now:<br>
<br>
UserData:<br>
  Fn::Base64:<br>
    Fn::Join:<br>
    - ''<br>
    - ["#!/bin/bash -v\n",<br>
        "/opt/aws/bin/cfn-init\n",<br>
        "sudo service trove-guest start\n"]<br>
<br>
Since you're using yaml, you don't have to se Fn::Join like in json,<br>
so simplify to this first:<br>
<br>
UserData:<br>
  Fn::Base64: |<br>
    #!/bin/bash -v<br>
    /opt/aws/bin/cfn-init<br>
    sudo service trove-guest start<br>
<br>
Now, the suggestion was that users might want to do a different prep<br>
per service_type. First, we need to make service_type a parameter<br>
<br>
<br>
Parameters:<br>
  service_type:<br>
    Type: String<br>
    Default: mysql<br>
<br>
Now we need to shove it in where needed:<br>
<br>
Metadata:<br>
  AWS::CloudFormation::Init:<br>
    config:<br>
      files:<br>
        /etc/guest_info:<br>
          content:<br>
            Fn::Join:<br>
            - ''<br>
            - ["[DEFAULT]\nguest_id=", {Ref: InstanceId},<br>
              "\nservice_type=", {Ref: service_type}, "]"<br>
          mode: '000644'<br>
          owner: root<br>
          group: root<br>
<br>
Now, if a user wants to have a different script:<br>
<br>
Mappings:<br>
  ServiceToScript:<br>
    mysql:<br>
      script: |<br>
        #!/bin/bash -v<br>
        /opt/aws/bin/cfn-init<br>
        sudo service trove-guest start<br>
    galera:<br>
      script: |<br>
        #!/bin/bash<br>
        /opt/aws/bin/cfn-init<br>
        galera-super-thingy<br>
        sudo service trove-guest start<br>
<br>
<br>
And then they replace the userdata as such:<br>
<br>
UserData:<br>
  Fn::FindInMap:<br>
    - ServiceToScript<br>
    - {Ref: service_type}<br>
    - script<br>
<br>
Please can we at least _try_ not to reinvent things!<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>