You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
implement _write_hostname() without hostnamectl (some distros do it already)
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
The text was updated successfully, but these errors were encountered:
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 tonetwork.service
is a systemd commit from 2015 which fixed a typo fromnetwork.service
tonetwork.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 beforeNetworkManager.service
and beforenetwork-pre.target
, yetNetworkManager.service
is itself ordered afternetwork-pre.target
. In this example,cloud-init-local.service
doesn't need to be ordered beforeNetworkManager.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. OrderingAfter=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:
_write_hostname()
withouthostnamectl
(some distros do it already)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
The text was updated successfully, but these errors were encountered: