cloud-init team mailing list archive
Mailing list archive
Re: cloud-config YAML variable substitution
On Wed, 12 Jun 2013, Ivan Voras wrote:
> I'm not sure this is the place to ask my question, and it any case
Most definitely the right place to ask.
> this is something which looks so trivial that I must be missing
> something, but - how to parametrize the cloud-config YAML files with
> variable expansion?
> Specifically, I need it for a scenario where I'm installing chef with
> cloud-init, and one of the attributes chef has is "node_name" which if
> not set defaults to the instance id, a string of the form
> "i-0000009f". This non-human-readable string then gets registered as
> the node name in Chef, but instead of that, I'd like to use the
> hostname as created and passed by the cloud infrastructure (OpenStack
> in my case).
> I'm sure this is not the only place where it would be nice to
> customize the cloud-config data with some actual dynamic information
> so - how can it be done? I've tested some of the "usual suspects" in a
> string like "test %(hostname) %(fqdn) %(instance_id) $fqdn %f
> $INSTANCE_ID" but none of those work.
> Any ideas?
cloud-config data is not 'rendered' itself in any way. Ie, it doesn't do
variable substitution in the cloud-config content before processing.
Some config-modules consider input to them to be cheetah template content.
One example is the apt_configure that allows apt-source lines that are
added to contain: $RELEASE or $MIRROR.
'update_etc_hosts' is another one. It uses a template in
/etc/cloud/templates that can have variables in it. There is a request
for access to more variables (similar to what you're asking for) in bug
Both your request and the one above do seem reasonable, and it might make
sense to extend the chef config module with access to more variables.
In a "less integrated" manner, I'd also like to see the return of
"cloud-init-query". If you've used ec2, you might be familiar with the
$ ec2metadata --instance-id
The goal of cloud-init-query would be to provide access to similar
information, but in a data-source agnostic way. Ie 'cloud-init-query
--instance-id' would "just work" on ec2 and on openstack with config-drive
or even the local data source.
It may make good sense to basically provide access to all the same
variables or data that 'cloud-init-query' would have.
So, unfortunately I don't have a simple answer to get you unstuck, but I
am interested in thinking about this, and interested in feedback,
thoughts, solutions, patches ...