[announcement] Cloud-init Perfomance Optimization: Single Process

Server cloud-init
1

Cloud-init is getting a speed boost in 24.3!

Read on to understand what this means for you.

I am a cloud-init user

If your distribution uses systemd, cloud-init should “just boot faster”. You shouldn’t have to change anything[1]. However, some distributions may choose to patch this change out of stable releases for backwards compatibility. In Ubuntu, this improvement is available in 24.10 (Oracular Oriole). Please test it and report bugs.

This change includes improved systemd integration. Cloud-init’s standard output logs are now available in a single service: journalctl --unit=cloud-init-main.service. Each cloud-init systemd service also has additional debugging information in the output of systemctl status <service>.

The cloud-init init and cloud-init modules commands are officially deprecated. Cloud-init is intended to run at boot time and be started by the init system. Please request an enhancement on the issue tracker complete with details if this does not address your use case.

I am a cloud-init distro maintainer (systemd)

How it works:

In 24.3, cloud-init switches from four separate Python processes to a single process which the init system triggers to start using Unix domain sockets. This avoids duplicate work including interpreter startup and library load time.

There are a few things that you should know:

  • cloud-init.service is renamed to cloud-init-network.service[2]. Any systemd services that have dependency or ordering requirements on cloud-init.service must be updated to the new name.
  • Runtime order under systemd is otherwise unchanged.
  • See this patch to revert this change in stable releases.
  • Critical error failure paths may be slightly different ways than before.

For more details see the breaking change docs and the commit message.

I am a cloud-init distro maintainer (non-systemd)

We want your contributions! The old command line arguments remain (for now). Implementing this for alternative init systems should be straightforward[3], but community engagement with testers is required. Get in touch on the mailing list or IRC (#cloud-init on Libera).

[1] This is not true if you manually add your own systemd services. If you add your own custom service which manually depends on cloud-init.service, see the systemd distro maintainer section.
[2] The old name was confusing for developers and users alike, and the new name matches the stage that actually runs.
[3] The implementation relies on cross-platform technologies: Unix domain sockets and openbsd’s netcat (a pure-python replacement is also possible if needed). The systemd-specific parts should be a no-op. An implementation would involve making this command run first, then replace each of the current cloud-init commands with the stage-specific synchronization command.

1 Like