Need jinja templating in config files

Hello and thanks for your bug report. Cloud-init already supports jinja templating [1], does this cover your use case? If it doesn't, could you please explain a bit better what you are trying to achieve an how it's not covered by the current templating capabilities? Thanks!

https://cloudinit.readthedocs.io/en/latest/topics/instancedata.html?highlight=jinja#using-instance-data

I just try to add configurations in the /etc/cloud/cloud.cfg.d/ directory and it doesn't seem to apply with the example I sent.

[Expired for cloud-init because there has been no activity for 60 days.]

I have extensively tested this.

jinja templating only works for #cloud-init config in userdata and vendordata. The built-in handlers are only invoked for those 2 files here: https://github.com/canonical/cloud-init/blob/main/cloudinit/stages.py#L783-L799

It's a really desirable feature to have this work for configs inside /etc/cloud/cloud.cfg.d/ directory as well. The code is parsing all these files as part of fetch_base_config() but it simply loads the yaml and merges the dictionary. https://github.com/canonical/cloud-init/blob/343d2c72f32db8fbe47eb8afa98c15987e9ffba6/cloudinit/stages.py#L966

I can't re-open this bug I guess I will open a new one

I triaged just now, so no new bug needed.

Thanks! Is there a chance of bumping the importance on this bug?

Or is there a workaround in the interim until this is fixed?

As far as importance, it's a feature request, not a bug, so I don't think it makes sense to bump the priority. (Outside of NoCloud) Userdata was never intended to be defined in /etc/cloud.cfg[.d]. This is something that has been discussed between the upstream developers, and something I think we'd like to add, but that needs to be measured against the other 20 competing priorities. We certainly welcome contributions though!

As far as workarounds, if you happen to be using NoCloud, see the example here:
https://cloudinit.readthedocs.io/en/latest/topics/examples.html#configure-data-sources

Beyond that, is there a reason you can't define your #cloud-config in vendordata or userdata as designed by cloud-init?

We are using cloud-init configs to manage dynamic pieces of boostrapping an instance and embed it inside an AMI itself. We don't have control over the contents of user data since the users of the AMI configure that. It's a bad contract for us to place something in that.

Also the documentation implies that jinja templating is supported in cloud configs - I think this is where developers are getting the impression that it may be alerady supported: https://cloudinit.readthedocs.io/en/latest/topics/instancedata.html#using-instance-data

```
As of cloud-init v. 18.4, any instance-data can be used in:
User-data scripts
Cloud config data
Command line interface via cloud-init query or cloud-init devel render
```

Lastly, if you were open to this getting upstreamed - could we get a summarized understanding of how and which part of code that may be implemented. It's not obvious to me what it would take to run the handler code during parsing of cloud config yamls.

"We are using cloud-init configs to manage dynamic pieces of boostrapping an instance and embed it inside an AMI itself. We don't have control over the contents of user data since the users of the AMI configure that. It's a bad contract for us to place something in that."

That sounds like the exact use case of vendordata. Have you considered using vendordata instead of trying to put things in /etc/cloud? https://cloudinit.readthedocs.io/en/latest/topics/vendordata.html

"Also the documentation implies that jinja templating is supported in cloud configs"

Thanks, this is good feedback. When the documentation talks about cloud config, it's referring to the #cloud-config format that is part of userdata, not anything in /etc/cloud. See https://cloudinit.readthedocs.io/en/latest/topics/format.html#cloud-config-data
Jinja templating is supported in cloud configs, but cloud configs aren't supported in /etc/cloud. We'll see if we can update the documentation to make it more explicit what's being referred to.

"Lastly, if you were open to this getting upstreamed - could we get a summarized understanding of how and which part of code that may be implemented. It's not obvious to me what it would take to run the handler code during parsing of cloud config yamls."

That's not something I perfectly know myself, but the basic steps would look something like,
1. Identify a #cloud-config header when loading configs defined under /etc/cloud . https://github.com/canonical/cloud-init/blob/main/cloudinit/stages.py#L230
2. Save the #cloud-config data to be processed later.
3. When building the vendordata and userdata, also include the cloud.cfg.d data into the merging process. https://github.com/canonical/cloud-init/blob/main/cloudinit/stages.py#L672

"Also the documentation implies that jinja templating is supported in cloud configs" +1 on that, we opened a support case based on this assumption.

Our use case for jinja templating on /etc/cloud files is we wanted to use cloud-init landscape client registration passing {{ v1.local_hostname }} to it's computer_title, so newly created machines using this particular ubuntu image on openstack would automatically register themselves on our landscape server.

This bug is believed to be fixed in cloud-init in version 22.4. If this is still a problem for you, please make a comment and set the state back to New

Thank you.

Tracked in Github Issues as https://github.com/canonical/cloud-init/issues/3835