use of local-hostname in cloudinit

[cob-web-corner]

In this documented example, the hostname is set using a meta data configuration local-hostname. I cannot seem to find this documented anywhere in the cloudinit documentation.

If I used the cloudinit hostname module that is document instead (see example below) the hostname will not get set. With the example code using local-hostname the hostname does get set properly but not the entire fqdn only the host.

What's going on here?

Here's what I did instead, based on this doc, and it does not work:

  source_raw {
    data = <<EOF
hostname: example
create_hostname_file: true
fqdn: example.domain.local
prefer_fqdn_over_hostname: true
    EOF

    file_name = "meta-config.yaml"
  }

In the logs I see the step/module where it goes to write the hostname but it's not catching it when using the cloudinit documented method

[bpg]

Hey @cob-web-corner

Here's the reference for local-hostname. It’s admittedly not the easiest thing to find.

I think this configuration might work for you:

local-hostname: external.fqdn.me
prefer_fqdn_over_hostname: false

It’s also worth mentioning that cloud-init implementations can vary slightly between Linux distributions, so not all examples work universally, at least in my experience 🤷🏼

[cob-web-corner]

local-hostname: external.fqdn.me
prefer_fqdn_over_hostname: false

Okay so this did not end up working but it did prompt me to tear into cloudinit a little ahead of schedule (I'm new to cloud init, I usually customize at the packer stage).

First and foremost, the older versions of the cloudinit documentation are much better in explanation and format (v22.4.2). Anywho..

It appears metadeta is more aligned to vendor-data than user-data which is behind the cause of my original confusion. If you launch a cloudinit image with a valid user-data file you can dump the entire cloudinit's final json by running sudo cloud-init query --all and see the relation between them from a data point of view.

https://cloudinit.readthedocs.io/en/22.4.2/topics/instancedata.html#v1-local-hostname defines local_hostname a little more rigidly than the new documentation, local_hostname is sort of a limited version compared to the options in user-data. I'm assuming this is available to make the hostname available earlier to the machine (and cloud/hypervisor) for relationships.

In the 5 stages of cloud init:

1. Generator
2. Local (https://docs.cloud-init.io/en/22.4.2/topics/boot.html#local)
3. Network
4. Config
5. Final

the metadata gets injected during step 2, and userdata gets injected during step 3. This validates my above assumptions with making certain network configurations (including local_hostname) available before other steps/modules get executed. An "early and limited" configuration to help bootstrap the instance.

Back to my original question, the original intention was to keep my cloud-init file generalized and not templated by trying to use the metadata to help setup certain aspects of configuration that could be created at terraform apply time. It looks like I'll have to go down another route, but boy did I learn about cloudinit.

Anyways great work on this provider @bpg, it's working very well and as expected in every aspect (no gotchas).

[cob-web-corner]

Weirdly enough right after I got done writing that I decided to just try and break it, what do you know, this works:

local-hostname: external
hostname: external.fqdn.me

and

hostname: external.fqdn.me

[cob-web-corner]

Thanks @bpg! I'll give that a go when I have an extra minute

It’s also worth mentioning that cloud-init implementations can vary slightly between Linux distributions, so not all examples work universally, at least in my experience 🤷🏼

You're absolutely right because on my other distro cloudinit images this has been working fine, ubuntu was being used for the above question, which is humorous because the documentation is written by Canonical.