cloud-init team mailing list archive
-
cloud-init team
-
Mailing list archive
-
Message #00014
Re: cloud-config YAML variable substitution
On Wed, 12 Jun 2013, Ivan Voras wrote:
> Hello,
>
> 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
1020695 (http://pad.lv/1020695).
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
'ec2-metadata' command:
$ ec2metadata --instance-id
i-00003c0a
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 ...
Scott
References