@dj423
After a bit more digging, I see from the XO cloud config, to the config drive is where the characters get switched - here is the output of
xo-cli cloudConfig.getAll
id: 'e7655d9f-c442-4c0f-8e16-35bf3e5e5685',
name: 'Prod-RL9-jinja',
template: '## template: jinja\n' +
'#cloud-config\n' +
'fqdn: {name}%\n' +
"{% set u1 = 'user' %}\n" +
"{% set u1pass = '$6$xxxxxxK0q11t/' %}\n" +
Everything looks correct, and matches the config as in XO cloud configs. All good so far.
Mounting the cloud config drive I see something different, and why it is failing - cloud init is choking on the {0 's
mount /dev/xvda /mnt
cat /mnt/user-data
root@test1:/mnt/userdata# cat user-data
## template: jinja
#cloud-config
fqdn: RL9-jinjatest0
{0 set u1 = 'user' 0}
{0 set u1pass = 'xxx/' 0}
{0 set u1key = 'xxxx xx-ed25519-ansible' 0}
All of the % characters are now 0's. See it in the hostname as well as jinja.
Anyone know what part of the process (where it reads the cloud-init userdata and packages into the config disk) would flip all %'s to 0's?? When I run tests on the original userdata config, everything renders fine when I test it with cloud init in the VM instance, so I don't think the issue is with cloud-init.
ex: cloud-init query --format="$( cat userdata.yaml )"
When I feed the same userdata config to xo-cli vm.create everything renders fine, it just doesn't have the metadata for the hostname. Really strange. I will keep digging, and try a few test configs for giggles.