Ubuntu: cloud-init.service order After=NetworkManager.service not possible with Before=sysinit.target
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cloud-init |
Expired
|
Medium
|
Unassigned |
Bug Description
For Ubuntu Desktop images which prefer NetworkManager as the primary network configuration service, provide a mechanism by which cloud-init.service can be ordered After=NetworkMa
Use case:
The Ubuntu desktop live installer ISO prefers using NetworkManager as the primary network backend and cloud-init must order After=NetworkMa
Issue:
Upstream Ubuntu packaging of systemd cloud-init.service file declares ordering as After=systemd-
Fix Proposal:
Short-term fix is released which provides an override for cloud-init.service in the livecd-rootfs project[3]
Mid-term need is to provide an environmental artifact or mechanism at systemd-generator timeframe to allow cloud-init.service to order After=NetworkMa
Since NetworkManager.
cycles punting cloud-init out of the boot target.
Long-term want:
Ideally, we may want to see NetworkManager.
But NetworkManager growing support for earlier boot before dbus.service is probably a longer term goal for NetworkManager than cloud-init.service allowing flexibility at systemd generator timeframe to prefer NetworkManager over networkd for certain images/
[1] https:/
[2] https:/
[3] livecd-rootfs cloud-init.service overrides https:/
[4] functional changes allowing networkd to set hostname at some point after networkd start when dbus service shows up https:/
[5] networkd dropping After=dbus.service ordering https:/
Changed in cloud-init: | |
importance: | Undecided → Medium |
description: | updated |
> Mid-term need is to provide an environmental artifact or mechanism at systemd-generator timeframe to allow cloud-init.service to order After=NetworkMa nager.service and drop Before= sysinit. target for that use-case.
How broad are we considering this use-case? Any image that uses NetworkManager? Only some specialized NoCloud images? Something else?
This change would cause cloud-init to no longer be blocking "as much of the remaining boot as possible"[1].
Dropping Before= sysinit. target from cloud-init.service could cause other services later in boot that are expecting cloud-init.service to be done by sysinit.target to fail. We could easily test base images, however I don't think this would be sufficient, since any package could provide a service that is ordered After=sysinit. target. Any service that currently orders after sysinit.target and expects cloud-init mounts/disk setup to be complete, for example, could be broken by the proposed change.
[1] https:/ /cloudinit. readthedocs. io/en/latest/ explanation/ boot.html# network