cloud-init

Overview

cloud-init is the upstream project for initializing and customising cloud instances on first boot. It reads instance metadata and optional user-provided or vendor-provided data, then applies the requested system configuration during boot.

In a Linux distribution, this package provides the tooling and integration needed for images that are expected to boot in cloud or other metadata-driven environments. NiceOS maintainers should treat it as infrastructure software for provisioning, not as an application for direct interactive use.

Purpose and typical use cases

Typical use cases include:

• provisioning fresh virtual machines or images in public or private clouds
• applying first-boot configuration from user data or vendor data
• configuring host identity, users, SSH access, networking, storage, and other instance settings when supported by the selected datasource
• supporting automated image builds and CI/CD workflows that need a predictable first-boot setup path
• helping administrators and platform engineers keep cloud images consistent across environments

Typical users include:

• cloud and systems administrators
• image builders and release engineers
• developers working on instance bootstrapping or datasource integration
• CI/CD maintainers who validate boot-time configuration behavior
• security engineers reviewing first-boot configuration inputs and image defaults

Upstream project

The canonical upstream project is maintained by Canonical and is developed in the canonical/cloud-init repository on GitHub. Launchpad also references the project and notes that its code there is a mirror of the official upstream repository. cloud-init documentation describes the project as handling cloud metadata, user data, and vendor data during instance initialization. (github.com)

Upstream documentation and source should be checked when updating the package, especially for changes in boot behavior, datasource handling, configuration syntax, or packaging-related files. NiceOS maintainers should verify any repository-specific assumptions against the current upstream documentation before relying on them. (github.com)

Dist-git repository contents

This dist-git repository is organized as follows:

• SPECS/ — RPM spec files and packaging logic
• SOURCES/ — source metadata and manifests used to track upstream inputs
• METADATA/ — repository metadata used by dist-git tooling
• SBOM/ — software bill of materials material, when provided by the packaging workflow

Large upstream source archives are intentionally not stored in this Git repository. Instead, source integrity is tracked through manifest files in SOURCES/, so the repository remains lightweight while still recording which upstream artifacts are expected for the package build. NiceOS maintainers should not treat the absence of the archive in Git as an error. (github.com)

Source storage and integrity policy

The repository follows a manifest-based source policy:

• upstream source archives are kept outside the Git tree
• the SOURCES/ manifests record the expected upstream inputs
• package updates should refresh the manifests and any packaging metadata that depends on them
• the exact integrity details are carried by the manifest workflow, not by handwritten notes in the README

When updating the package, verify that the manifest still points to the intended upstream release artifacts and that any local patches still apply cleanly. If the upstream release changes packaging expectations, NiceOS maintainers should review the spec and regenerate related files as needed.

NiceOS maintenance notes

Before updating this package, check the following:

• whether upstream changed boot-time behavior, supported datasources, or configuration syntax
• whether any downstream patches are still needed or can be dropped
• whether packaging metadata in SPECS/ needs to be aligned with upstream changes
• whether files under SOURCES/ need regeneration because the upstream inputs changed
• whether SBOM/ data or repository metadata needs a refresh after the update
• whether the update affects image boot behavior, first-boot scripts, or cloud-provider integration

Risks to consider:

• changes in cloud-init behavior can affect provisioning for already-built images
• datasource or metadata handling changes may alter how instances boot in different clouds
• packaging changes may require coordinated updates across spec files, manifests, and auxiliary metadata
• downstream assumptions about defaults should be rechecked after each upstream update

If any detail is unclear from the current repository state, NiceOS maintainers should verify it against upstream release notes and documentation before shipping the update.

Build and verification checklist

For a package update or rebuild, a maintainer should usually check the following:

• confirm that the upstream source referenced by the manifest is the intended one
• review the spec file for patch carryover, file list changes, and packaging script changes
• ensure the source manifests in SOURCES/ were updated consistently
• verify that any auxiliary metadata or SBOM material still matches the package contents
• build the RPM in a clean environment
• run the package test or sanity checks used by NiceOS for this repository
• boot-test the resulting image or package in at least one representative cloud or virtual environment if the update may affect first boot
• inspect logs for unexpected datasource, network, or service startup regressions
• confirm that no generated file was left stale after the update

References

• Upstream GitHub repository
• cloud-init documentation
• Launchpad project page
• cloud-init user-data formats
• cloud-init datasources reference

Russian documentation

See README_RU.md for the Russian version of this document.

Dist-git repository notes

• Package repository: rpms/cloud-init
• NiceOS branch: niceos-5.2
• This README is intentionally stable and does not include EVR, source archive checksums or lock hashes.