feat: check for create_hostname_file key before writing /etc/hostname

[catmsred]

Proposed Commit Message

Some users would like to be able to bring up their systems without automatically creating /etc/hostname if it does not exist already. On distros with systemd, the hostname/hostnamectl command can be used to set the hostname transiently (which does not create /etc/hostname).  To support this without changing previous behavior (that cloud-init will set the hostname statically and create /etc/hostname if it does not already exist), this change proposes a new key create_hostname_file which if true or not present, sets the hostname statically and creates the hostname file if it does not yet exist; if false, sets the hostname transiently and does not create the hostname file.

This change does not affect BSD or OpenBSD (or any distros that inherit their _write_hostname), as their hostname management does not use an /etc/hostname file.

Test Steps

This change adds unit tests for all non-BSD distributions to ensure that if the create_hostname_file key is set to False, their hostname files are not created. The existing test_cc_set_hostname tests look for /etc/hostname to confirm the hostname has been set correctly so they provide validation that without the create_hostname_file key, there are no regressions in behaviour.

References

Jira card: https://warthogs.atlassian.net/browse/SC-1588
SF case: https://canonical.lightning.force.com/lightning/r/Case/5008e00000EHIhYAAX/view

Checklist:

• My code follows the process laid out in the documentation
• I have updated or added any unit tests accordingly
• I have updated or added any documentation accordingly

[igalic]

BSDs store the hostname in rc.conf(5) like most of its config, but like most other Unices, they have a hostname(1) to (re)set it on the fly.

I can help bring it to feature parity

[catmsred]

@igalic Thank you for the offer! Looking through the BSD distro code, it looked to me like BSD and FreeBSD did update rc.conf as you say, but OpenBSD wrote /etc/myname. As in every other case, this write happens after the call the hostname. In most of the other systems that use /etc/hostname, the call to hostname will write to /etc/hostname if the file exists but will not create it if is does not exist. Prior to the proposed changed, cloud-init ALWAYS created /etc/hostname on a call to Distro.set_hostname() for those systems. So this change would allow a user to not automatically create /etc/hostname if it did not already exist (similar to hostname functionality). Is there an equivalent difference in BSD flavours? E.g., Do you know if /etc/myname or the hostname key in rc.conf is always created when hostname is run?

[igalic]

hostname(1) on all BSD hasn't changed much since 1993: it sets the sysctl(3) kern.hostname, and does nothing else.

The /etc/rc.d/hostname service on FreeBSD reads the hostname from /etc/rc.conf and uses hostname(1) to set it. On OpenBSD it's /etc/rc which reads /etc/myname doing the same. NetBSD does a mix of the two.

[blackboxsw]

Bikeshed schema key suggestion: having our preexisting preserve_hostname key makes this a bit tougher to name properly so other suggestions welcome.

        "write_etc_hostname": {
          "type": "string",
          "default": true,
          "description": "When true, statically set hostname across reboots by writing the appropriate hostname file under /etc with the preferred value from user-data and meta-data. Systemd prefers /etc/hostname, FreeBSD ``/etc/rc.conf`` or /etc/myname. Default: ``true``"
        },

Also, given BSDs will be using different etc files for persisting hostname maybe it's not ideal to call out etc_hostname specifcally? 2nd alternative write_hostname_file

[catmsred]

Re: keyname write_hostname_file

The original intention of this key would be to still write the file if it already existed. If it's named write_hostname_file that kind of implies to me that we never write to the hostname file even if it exists. Do we want that behavior (never write to hostname file) or would it make more sense to have the key named create_hostname_file?

[catmsred]

@igalic (and anyone else with an opinion) what would you consider the correct BSD behavior if the create_hostname_file key is false? On BSD/FreeBSD, the code already makes the assumption that /etc/rc exists so I assume there's no time we would expect the set_hostname or update_hostname configs to be creating it so it would make sense to me that this key is not relevant in these systems.

I'm still looking into the OpenBSD /etc/myname file and whether cloud-init currently creates it if it doesn't exist and if so whether we should in the case create_hostname_file is False.

[blackboxsw]

Re: keyname write_hostname_file

The original intention of this key would be to still write the file if it already existed. If it's named write_hostname_file that kind of implies to me that we never write to the hostname file even if it exists. Do we want that behavior (never write to hostname file) or would it make more sense to have the key named create_hostname_file?

@catmsred create_hostname_file works well. +1

[catmsred]

@s-makin
Recommended documentation update:
On https://cloudinit.readthedocs.io/en/latest/reference/modules.html#set-hostname and https://cloudinit.readthedocs.io/en/latest/reference/modules.html#update-hostname, add the following bullet to Config Schema:

• create_hostname_file: (boolean) If false, the hostname file (e.g. /etc/hostname) will not be created if it does not exist. If true, the hostname will always be created. Default: true.

[aciba90]

Thanks, @catmsred, for improving cloud-init. I did a superficial review.

New cloud-config keys need to be added to the json-schema, in order to be validated and documented.

So adding something like #4330 (comment) including #4330 (comment) will do it.

If you want to validate the rendered documentation, execute:

tox -e doc && (cd doc/rtd_html/ && python -m http.server)
open http://0.0.0.0:8000

[aciba90]

Overall, looks great, thanks. I have left inline requests to fix/improve some things.

In addition to that, could you please reference, in the PR main comment, the Jira and SF tickets associated to this PR for future back tracing?

[aciba90]

LGTM. Thanks, @catmsred.