[enhancement]: simplify systemd unit files

[holmanb]

Enhancement

Cloud-init's systemd service templates have grown in complexity over time. Changes to unit files have a broad impact, so to limit risk to other distros templates are sometimes used when making changes. Over time these templates have grown very complex, which has made them even more difficult to maintain and increased the risk of changes breaking one distro or another[1]. Some changes were made in the past to simplify these service files[2][3], but much complexity remains.

This complexity falls into four different categories:

Foregone spring cleaning

network.service doesn't appear used anywhere, if it ever was. The only reference that I can find to network.service is a systemd commit from 2015 which fixed a typo from network.service to network.target.

RHEL-family:

This looks like a requirement from before ds-identify was used. ds-identify creates this directory during generator timeframe. RHEL family distros use ds-identify, so I don't think that this is required anymore.

This also looks like a carry-over from pre-ds-identify adoption. This file is normally generated by the systemd generator so I assume that this was to make sure that cloud-init reported the correct status, but since RHEL family distros use ds-identify now it shouldn't be necessary - this will always exist when ds-identify runs and cloud-init's systemd services starts.

Is this is actually needed? Systemd loads the selinux security policy prior to running any cloud-init code (including the systemd generator), so won't the security policy already be the default one upon creation? If this actually is needed, it probably belongs somewhere besides this service file - either in cloud-init's code directly or elsewhere.

Redundant ordering

cloud-init-local.service is ordered before NetworkManager.service and before network-pre.target, yet NetworkManager.service is itself ordered after network-pre.target. In this example, cloud-init-local.service doesn't need to be ordered before NetworkManager.service. Other redundant orderings like this exist.

Unnecessary templating

Systemd allows ordering and dependency on units to behave correctly when referenced units do not exist. Ordering After=wicked.service will not harm distros which do not use Wicked. Ordering After=networking.service will not harm those distros not using ifupdown.

The dbus issue

Cloud-init can update hostname very early in boot. Some distro implementations in cloud-init[4] implement this with hostnamectl, which depends on D-bus. Those distros have to run all of cloud-init's services much later in boot after D-bus is available.

I see two ways to resolve this divergent behavior:

1. implement _write_hostname() without hostnamectl (some distros do it already)
2. wait for hostnamctl to become Varlink-aware since existing systemd APIs will slowly acquire Varlink interfaces (eta: unknown)

How to contribute

If you are a distro maintainer, your participation and help with this issue would be greatly appreciated. A comment if you have anything to add (or disagree with any of the above), or even just a thumbs up to indicate that you think the approach seems reasonable would go a long ways.

Appendix

[1] #5755
[2] ec7dde8
[3] #5620
[4] RHEL, arch, opensuse, aosc, and photon, as well as distros derived from these in cloud-init's code