Nested interpolation

[errordeveloper]

A two-level nested interpolation would be great.

Some of the usage examples would be:

• Interpolation in varible names names, e.g. ${vars.foo-${count.index}}
• Interpolation of arguments to a macro, e.g. ${file("foo-${count.index}")

[andyshinn]

I think this is the same as #408 and #611. Check out those issues. May be already fixed in 0.3.2 when released.

[mitchellh]

I can see the use case of this, but it would be an incredibly complex feature to add and the use cases just aren't there right now. What use case are you using this for? Perhaps we can come up with an alternate approach.

In the mean time, I'm going to close this as "wontfix" for now, since there is no short term future where we add this, unfortunately.

[errordeveloper]

@mitchellh I have found an alternative approach by now (blog post is coming). The one simple thing I wanted to concatenate a common head with a host-specific tail, like so:

user-data = ${file("common.yaml")}\n${file("host-specific-$index.yaml")}"

Templates (#642) would a very nice alternative, I think.

[zadunn]

fwiw - I ended up working around this issue by making cloudinit pull in and execute some scripts from S3. tl;dr - I didn't try to make cloudinit dynamic or drop a bunch of files, I just used EC2 tags and sed'ed the results. This does have the downside of a being a "master" cloudinit file, which means that any change and everything would get rebuilt. We work around that by versioning the file. we are still in early days, but I was surprised by how well it worked.

OTOH - Templates would be nice, and would let us just use cloudinit the way it was supposed to be used.

Example cloudinit:

#cloud-config

apt_update: true

packages:
  - curl
  - gcc
  - make
  - libxslt-dev 
  - libxml2-dev
  - awscli

runcmd:
  - [ curl, "https://s3.amazonaws.com/optoro-packages/update_hostname.sh", -o, /tmp/update_hostname.sh ]
  - [ sh, -c, "chmod +x /tmp/update_hostname.sh && /tmp/update_hostname.sh" ] 
  - [ sh, -c, "aws s3 cp s3://optoro-packages/optoro-chef_1.0_amd64.deb /tmp/optoro-chef_1.0_amd64.deb --region us-east-1" ]
  - [ sh, -c, "dpkg -i /tmp/optoro-chef_1.0_amd64.deb" ]
  - [ sh, -c, "sed -i s/`curl --silent http://169.254.169.254/latest/meta-data/instance-id`/`hostname`/ /etc/chef/client.rb"]
  - [ curl, "https://s3.amazonaws.com/optoro-packages/update_run_list.sh", -o, /tmp/update_run_list.sh]
  - [ sh, -c, "chmod +x /tmp/update_run_list.sh && /tmp/update_run_list.sh > /etc/chef/firstboot.json" ] 
  - [ sh, -c, "/usr/bin/curl -L https://www.chef.io/chef/install.sh | sudo bash -s -- -v 11.16.4-1" ]
  - [ chef-client ]  

chef:
 install_type: ""
 force_install: false
 server_url: "https://chef_server"
 environment: "development"
 validation_name: "chef-validator"

# Capture output into a logfile Useful for troubleshooting cloud-init issues
output: {all: '| tee -a /var/log/cloud-init-output.log'}

[errordeveloper]

In my case it's all based around systemd units and environment files, and I am using CoreOS. I am still working on the blog post, but here is the essence:

• cloud init provision all systemd units
• it starts only basic units where no host-specific environment files needed
• terraform execs a shell script that generates per-hosts environment files
• terraform start remaining systemd units

In this particular setup I do have all units run everywhere at the moment, just the environment files differ... But if I were to not run some on certain hosts, I'd use conditional start stanzas.

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.