cloud-init Cloud Config use of {name}

[bug-meister]

I'm starting to work with cloud-init and Cloud Configs. Setting the hostname is straighforward via:

hostname: {name}

This looks somewhat like a jinja template. Is the standard...

## template: jinja

...implicit here, or is this a special implementation? Can {name}, for example, be used elsewhere? Does it require the jinja format of {{ ref }} or not? If jinja is needed, I assume both python and jinja need to be installed in when the template is created, correct? I need to write a simple config file with the hostname in it.

What is the recommended approach? Thanks!

[bvitnik]

@bug-meister Nope. This is not Jinja nor any other kind of templating engine. This is a simple search-and-replace kind of implementation and is limited to name and %, the later being VM index. From the docs:

Xen Orchestra offers the ability to insert variables such as the virtual machine name {name} or a virtual machine index %. However, the expressive power is limited to the graphical interface. For instance, it is not possible to build a series of virtual machines with complex values or from external data.

Reference:

• https://docs.xcp-ng.org/guides/create-use-custom-xcpng-ubuntu-templates/

In other words, there is no advanced templating of cloud-init configuration but you could probably template it outside XenOrchestra and apply it via Terraform:

• https://registry.terraform.io/providers/vatesfr/xenorchestra/latest/docs/resources/vm

[bug-meister]

@bvitnik Thank you! I was hoping not to go so far as Terraform/OpenTofu or Ansible. I found this post from @dj423 suggesting that I may be able to accomplish what I'm hoping by installing jinja into the VM before I convert it to a template. However, it does NOT appear that I need to modify my template to install python or jinja -- they appear to be in place, perhaps as dependencies of cloud-init itself. I will test further!

[bvitnik]

@bug-meister Ah. That's cloud-init's support for templating user-data. The issue is that with these templates you only have access to the info available inside the VM itself. No outside data can be used for templating unless it is somehow passed to the VM (inject a file, set xenstore values...)

[bug-meister]

@bvitnik It worked as hoped, after an iteration or two. I opted for using jinja templating with setting template vars up top and using in standardized fashion below. But... I can see that cloud configs will not be easy to manage and scale for complex tasks. If you need to write a file or two, configure LDAP authN using sssd, the prometheus node_exporter, etc., the scripts can get lengthy. Given how difficult they are to debug (cloud-init schema --config-file <config.yaml> --annotate is helpful, but more challenging with jinja templates), it would seem something else should supplement a basic config.

Now I'm considering ansible-pull from an on-network git repo -- I don't think I have the scale to warrant a control instance and I can't quite warm up to the idea of an SSH key with sudo access everywhere. Admittedly the security concern just shifts to the repo, especially if periodic pulls will happen. In your opinion am I going in the right direction or should I be considering other config management options too? My goal is to deploy VMs with a set of docker containers (I'll use podman) in a repeatable fashion. Thanks again for your patience with a DevOps noob.

[bvitnik]

@bug-meister My opinion is that cloud-init should be used only for the most basic stuff like initial network configuration, initial user creation and credentials injection. As soon as you gain the ability to access the VM, some more robust configuration management solution like Ansible should take over.

ansible-pull mechanism is in today's day and age effectively deprecated. Just run Ansible after the VM has been provisioned to apply the configuration. If you need to call Ansible as soon as VM is provisioned without any manual invocation, you can have Terraform provision the VM and call Ansible right after that. You can even use pure Ansible for both - provisioning, with my community.general.xenserver_guest module, and configuration. You just invoke Ansible once and everything will be done in one go. The only drawback is that my module does not support cloud-init so you would need some trickery to do the stuff.