Phone Home Being Skipped?

1

Hi

I have been playing with this for a while but can’t remeber how I got it working before;

I see in the logs

cc_phone_home.py[DEBUG]: Skipping module named phone-home, no 'phone_home' configuration found

In my default profile (i know its bad) I set the user.vendor-data (i have tried user.user-data) to

#cloud-config

phone_home:
 url: http://MY_IP:8001/test
 post: [ pub_key_dsa, pub_key_rsa, pub_key_ecdsa, instance_id ],
 tries: 10

I have tried running (in the container)

cloud-init  clean
cloud-init --debug single --name phone_home

But there is little to no useful information,

So I then modified /usr/lib/python3/dist-packages/cloudinit/config/cc_phone_home.py to print out the cfg variable which got me

datasource_list
_log
log_cfgs
output
users
disable_root
preserve_hostname
cloud_init_modules
cloud_config_modules
cloud_final_modules
def_log_file
syslog_fix_perms
vendor_data

Its doing a check if 'phone_home' not in cfg: which is failing, and causing the above warning

If I curl this url from within the container its no problem

Edit 1

Okay so I was being an idiot running cloud-init clean removes all passed data, but it still doesn’t run on first run!

** Edit 2 **

After running cloud-init init I found that my YAML syntax was wrong (notice the comma) in the cloud-config, good job me!

Thanks

2

Thanks for editing the post and adding the solution (the leftover comma had to go).

LXD does not perform any sanity check on the cloud-init instructions, therefore if something goes wrong, you need to look into the container for hints.

3

Indeed and to be clear, if there was an easy way to validate those keys, we would do so.
Sadly because cloud-init accepts a very wide variety of user data, this isn’t practical, though maybe we can detect those that should be yaml and validate that the yaml parses properly at least.

We’ve also been talking with the cloud-init team regularly about having them use our /dev/lxd interface rather than using the current templating approach. With this in place, we should be able to make cloud-init more of a first class citizen in LXD and hopefully add more validation then.

4

Yeah as i sat there scartching my head as to why it wasnt validated i checked the docs and realised it would have been a pain :roll_eyes:

Thats really exciting that could-init could be made a first class citizen,

dare to speculate what that might mean for LXD or is it client tools that will mainly feel the benefit?

5

Mostly client tools, we’d likely rename the config keys to something more official and add some validation and tests, but that’d probably be the extent of it.