chore(cloud-init): truncate hostnames in determineHostname

[RiRa12621]

truncate too long hostnames

Long hostnames can have unexpected consequences and this makes the truncation behavior explicit

This also cleans up existing truncating in AWS

How to use

A new node that uses cloud init and has an overly long host name.

Technically the second case should never happen, because most cloud providers are attempting to block direct instance names longer than 63 chars, but rather safe than sorry.

Testing done

Test added for

• truncate on first .
• truncate at 63 chars if segment before first . is still too long

• Changelog entries added in the respective changelog/ directory (user-facing change, bug fix, security fix, update)
• Inspected CI output for image differences: /boot and /usr size, packages, list files for any missing binaries, kernel modules, config files, kernel modules, etc.

This is an alternative to #30

In this suggestion, all truncation happens centrally instead of for each metadata service. This reduces code duplication.

[jepio]

@RiRa12621 unit tests have failed

[RiRa12621]

@jepio should be fixed, please re-run the test

[gabriel-samfira]

There was a discussion at some point about using the FQDN vs the short name as the hostname (and potentially adding the fqdn in /etc/hosts). Some projects (like afterburn) prefer to use the FQDN, some projects prefer the short name.

I think that if the hostname is too large, we should make an attempt to use the short name. After which we should truncate the short name if it continues to be too large.

The reason is that this way, we at least get a valid hostname, and not a truncated FQDN (if the short name is within the 63 character limit). The full FQDN will still be valid if set in /etc/hosts along side the short name (if each element of the hostname is itself valid).

@jepio @RiRa12621 what do you folks think?

[gabriel-samfira]

For example, if we have something like this:

#cloud-config
hostname: this-hostname-is-precisely-than-sixty-three-characters-in--size.example.com

And we truncate at 63 using the logic here, we get: this-hostname-is-precisely-than-sixty-three-characters-in--size. Which is fine.

But if we have:

#cloud-config
hostname: this-hostname-is-a-bit-larger-than-sixty-three-characters.example.com

we end up with: this-hostname-is-a-bit-larger-than-sixty-three-characters.examp. Which is neither the FQDN that we want, nor a short name. If we go with the short name approach, we at least end up with a valid short name of this-hostname-is-a-bit-larger-than-sixty-three-characters, and we can set the correct FQDN in /etc/hosts.

[jepio]

For the second example, the code does the split on . before truncating, so the outcome is exactly as you describe (we don't end up with a partial FQDN).

I think in general the hostname and (/etc/hostname) should be just the first label, and the FQDN should be resolved through DNS.

cloud-init and coreos-cloudinit support manage_etc_hosts: true for those who need it.