@bvitnik

ansible-pull mechanism is in today's day and age effectively deprecated.

Really? I see evidence that the CLI command is, or will be deprecated (here), but the "mechanism" still remains, correct? The cloud-init docs still direct to examples (ref) such as:

#cloud-config
ansible:
  package_name: ansible-core
  install_method: pip
  pull:
    - url: https://github.com/holmanb/vmboot.git
      playbook_names: [ubuntu.yml, watermark.yml]

What is not entirely clear is when this will be executed... but perhaps your advice to to apply the KISS principle to cloud-init just makes that irrelevant. Time to learn some basic Ansible and experiment! Thanks again!

@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 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!

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!

@MichaelCropper, thank you for the additional details. I followed everything up to mounting the CDrom. Instead I chose to follow the instructions here instead: https://gitlab.com/xen-project/xen-guest-agent/-/releases

BTW... removing the old package may leave some residual config files behind. It should be safe to add --purge to the apt remove command. If not, you may need to do it using dpkg later. I listed all the packages with residual config using:

sudo dpkg -l | grep "^rc" | tr -s ' ' | cut -d ' ' -f 2

...and once I was sure of doing so for all packages, I followed with:

sudo dpkg --purge $(COLUMNS=200 dpkg -l | grep "^rc" | tr -s ' ' | cut -d ' ' -f 2)

If there is a downside to using the gitlab package rather than the tools on the CDrom, I'm hoping someone will let me know!

@bvitnik Thank you -- very useful information!

We have a small, two-host pool, having just added a new host. The master is a Dell R640 (Intel(R) Xeon(R) Gold 6150 CPU @ 2.70GHzIntel(R) Xeon(R) Gold 6150 CPU @ 2.70GHz) and the second, an R630 (Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz). I attempted to migrate a VM to the second host as a test and received the error:

"code": "VM_INCOMPATIBLE_WITH_THIS_HOST",
  "params": [
    "OpaqueRef:<UUID1>",
    "OpaqueRef:<UUID2>",
    "VM last booted on a CPU with features this host's CPU does not have."
  ],...

I don't see much other detail that seems to offer clues. How do I determine what the incompatibility actually is? If the incompatibility is determined, is there some means of disabling features to ensure capatibility?

I did try a different VM and the migration worked!?