Posts made by p4-k4

What does your cloud config logs show on the guest OS after boot?

Can you see if it has made any attempt to inject the config?
Only thing I can think of is that your cloud config might be wrong thus the cloud init service is refusing it.

Have you tried to use an ubuntu image? I used official images of both debian 10 and ubuntu 18.04 and worked fine once I got rid of the pre-populated network config or inserted a real network config.

I spent too long trying to figure out what was going on so let me know if there's anything else you need to know, it's super frustrating.

I had the same problem with Debian 10 also.

In my findings it seemed that the "commented out" network config that XO ships with was throwing it off.

The workaround in my case was...

1. Insert my cloud-config as per usual.
2. Remove everything from the network config box (if I didn't want cloud-config to set this up for me).

or

3. Insert a proper network config if I wanted network setup also.

Hope that helps

@fohdeesha

I thought commenting every line with # would be valid YAML which is how you guys have it as default.

Which is cuasing the problem at least on my side of things.

Hmm so it seems that clearing the box completely also leaves no errors and functions as expected.

Leaving it in with comment markers seems to trigger the error from what I can tell.

Maybe someone else can replicate the issue to confirm. I'm using a clean Ubuntu 18 image.

@fohdeesha

These are the logs from spinning up without configuring a network through cloud-init. As mentioned, all lines are commented out with # in the pre-populated text.

https://pastebin.ubuntu.com/p/4McRtgYR7f/

https://pastebin.ubuntu.com/p/q7BHQ7qW8k/

@olivierlambert

I haven't tried with an empty network config.

All I done was remove the # from the first two lines in the network config which then allowed the VM to utilize the cloud config drive.

Solved - At least in this case, network config must be specified otherwise nothing will happen.

YAML is all good, but it's clunky.

It would be nice to have an option in the cloud config section to specify common cloud-init parameters in a form. Both user specified entries and options for fixed state parameters. As an example...

User defined:

• hostname
• user
• password
• bootcmd
• additional user specified parameters

Fixed state/toggle:

• chpasswd: {expire: true/false}
• package_upgrade: true (update guest OS upon first login)
• growpart (auto)

Multiple choice:

• groups
• distro specific package installs

The ability to map more XO/XCPNG specific variables would be convenient too such as

• host domain -> guest domain
• custom login splash (xcpng host and domain info)

Cheers

@mietek said in XO debian 10 cloud ready VM template (cloud-init):

You gents need a proper manual/documentation because as of now it's just a slipshod work.
All of this is just so disappointing ...

What is this sulking? Pathetic... Go somewhere else, what an ungrateful piece of shit.

Is this a XOA registered feature only or? I'm almost certain I've done everything correct after probably 50 varied attempts.

@olivierlambert Sorry to hound you mate.

Yeah not too much from logs other than it's loads in the user created during installation. Although it does look like it is loading in some metadata but not clear if it's from the Cloud config drive that XO creates or what. Either way, it's not the metadata specified in my cloud config.

Can you confirm if the interactive configuration using

dpkg-reconfigure cloud-init

Is the right way to go? Or should I be adding the datasource in the cloud.cfg file?

@olivierlambert

I've configured it to use NoCloud using

dpkg-reconfigure cloud-init

However, no such luck again.

Should I be configuring it to use NoCloud in /etc/cloud/cloud.cfg rather than using the interactive setup?

If so, what should that look like? I see an entry there for EC2 as a datasource, not sure what NoCloud should look like this.

Cheers

Oh god... I was referencing your old blog posts, wasn't aware of these changes thanks.

Will give this a go!

I've managed to have my cloudinit config inject successfully once a while ago and I believe I am following the same process although it's not a difficult process to screw up anyway.

Now however, it seems the guest VM is not injecting the config. Not even the user I created in the installation is removed, so then I am still able to login.

Upon checking the cloud.cfg file - it appears as though it is unchanged and default, not even a hostname change or user configuration.

The process I'm using is as follows:

1. Create VM with official Ubuntu 18.04.4 Live ISO (on self-compiled latest of XO)
2. Disk partitioning - I just use the entire disk
3. The default cloud.cfg that Ubuntu ships with is fine - no modification required.
4. Chose Openstack Config drive as the one and only source (do we need to tell it to use the Openstack metadata config too? Although I tried this didn't seem to yield any results anyway.)
5. Finish up, remove traces of my user, halt the machine, convert to template.

Using

#cloud-config
hostname: test

No results however, I can see that the Config drive is indeed mounted in the system after boot.

Log shows that it does in fact attempt to set hostname

2020-08-21 07:50:33,280 - stages.py[DEBUG]: Running module set_hostname (<module 'cloudinit.config.cc_set_hostname' from '/usr/lib/python3/dist-packages/cloudinit/config/cc_set_hostname.py'>) with frequency once-per-instance

Any clues? Thanks!