Contributing to cloud-init
This document describes how to contribute changes to cloud-init.
It assumes you have a GitHub account, and refers to your GitHub user
Submitting your first pull request
Before any pull request can be accepted, you must do the following:
Sign the Canonical contributor license agreement
Add yourself (alphabetically) to the in-repository list that we use to track CLA signatures: tools/.github-cla-signers
Add or update any unit tests accordingly
Add or update any integration tests (if applicable)
Format code (using black and isort) with tox -e do_format
Ensure unit tests and linting pass using tox
Submit a PR against the main branch of the cloud-init repository
The detailed instructions
Follow these steps to submit your first pull request to cloud-init:
To contribute to cloud-init, you must sign the Canonical contributor license agreement
If you have already signed it as an individual, your Launchpad user will be listed in the contributor-agreement-canonical group. (Unfortunately there is no easy way to check if an organization or company you are doing work for has signed.)
When signing it:
ensure that you fill in the GitHub username field.
when prompted for ‘Project contact’ or ‘Canonical Project Manager’, enter ‘James Falcon’.
If your company has signed the CLA for you, please contact us to help in verifying which Launchpad/GitHub accounts are associated with the company.
For any questions or help with the process, please email James Falcon with the subject, “Cloud-Init CLA”
You also may contact user
#cloud-initchannel on the Libera IRC network.
Configure git with your email and name for commit messages.
Your name will appear in commit messages and will also be used in changelogs or release notes. Give yourself credit!:
git config user.name "Your Name" git config user.email "Your Email"
Sign into your GitHub account
Fork the upstream repository on Github and clicking on the
Create a new remote pointing to your personal GitHub repository.
git clone git://github.com/canonical/cloud-init cd cloud-init git remote add GH_USER email@example.com:GH_USER/cloud-init.git git push GH_USER main
Read through the cloud-init Code Review Process, so you understand how your changes will end up in cloud-init’s codebase.
Submit your first cloud-init pull request, adding yourself to the in-repository list that we use to track CLA signatures: tools/.github-cla-signers
.github-cla-signersis sorted alphabetically.
(If you already have a change that you want to submit, you can also include the change to
tools/.github-cla-signersin that pull request, there is no need for two separate PRs.)
Transferring CLA Signatures from Launchpad to Github
For existing contributors who have signed the agreement in Launchpad
before the Github username field was included, we need to verify the
link between your Launchpad account and your GitHub account. To
enable us to do this, we ask that you create a branch with both your
Launchpad and GitHub usernames against both the Launchpad and GitHub
cloud-init repositories. We’ve added a tool
tools/migrate-lp-user-to-github) to the cloud-init repository to
handle this migration as automatically as possible.
The cloud-init team will review the two merge proposals and verify that the CLA has been signed for the Launchpad user and record the associated GitHub account.
If you are a first time contributor, you will not need to touch Launchpad to contribute to cloud-init: all new CLA signatures are handled as part of the GitHub pull request process described above.
Do these things for each feature or bug
Create a new topic branch for your work:
git checkout -b my-topic-branch
Make and commit your changes (note, you can make multiple commits, fixes, more commits.):
Apply black and isort formatting rules with tox:
tox -e do_format
Run unit tests and lint/formatting checks with tox:
Push your changes to your personal GitHub repository:
git push -u GH_USER my-topic-branch
Use your browser to create a pull request:
Open the branch on GitHub
You can see a web view of your repository and navigate to the branch at:
Click ‘Pull Request`
Fill out the pull request title, summarizing the change and a longer message indicating important details about the changes included, like
Activate the frobnicator. The frobnicator was previously inactive and now runs by default. This may save the world some day. Then, list the bugs you fixed as footers with syntax as shown here. The commit message should be one summary line of less than 70 characters followed by a blank line, and then one or more paragraphs wrapped at 72 characters describing the change and why it was needed. This is the message that will be used on the commit when it is sqaushed and merged into main. If there is a related launchpad bug, specify it at the bottom of the commit message. LP: #NNNNNNN (replace with the appropriate bug reference or remove this line entirely if there is no associated bug)
Note that the project continues to use LP: #NNNNN format for closing launchpad bugs rather than GitHub Issues.
Click ‘Create Pull Request`
Then, a cloud-init committer will review your changes and follow up in the pull request. Look at the Code Review Process doc to understand the following steps.
Feel free to ping and/or join
#cloud-init on Libera irc if you
have any questions.
This section captures design decisions that are helpful to know when hacking on cloud-init.
Cloud-init upstream currently supports Python 3.6 and above.
Cloud-init upstream will stay compatible with a particular python version for 6 years after release. After 6 years, we will stop testing upstream changes against the unsupported version of python and may introduce breaking changes. This policy may change as needed.
The following table lists the cloud-init versions in which the minimum python version changed:
Cloud Config Modules
Any new modules should use underscores in any new config options and not hyphens (e.g. new_option and not new-option).
Submissions to cloud-init must include testing. See Testing for details on these requirements.
Feature flags are used as a way to easily toggle configuration at build time. They are provided to accommodate feature deprecation and downstream configuration changes.
Currently used upstream values for feature flags are set in
cloudinit/features.py. Overrides to these values (typically via quilt
patch) can be placed
in a file called
feature_overrides.py in the same directory. Any value
feature_overrides.py will override the original value set
Each flag should include a short comment regarding the reason for the flag and intended lifetime.
Tests are required for new feature flags, and tests must verify all valid states of a flag, not just the default state.
- cloudinit.features.ALLOW_EC2_MIRRORS_ON_NON_AWS_INSTANCE_TYPES = False
When configuring apt mirrors, if
Truecloud-init will detect that a datasource’s
availability_zoneproperty looks like an EC2 availability zone and set the
ec2_regionvariable when generating mirror URLs; this can lead to incorrect mirrors being configured in clouds whose AZs follow EC2’s naming pattern.
As of 20.3,
Falseso we no longer include
ec2_regionin mirror determination on non-AWS cloud platforms.
If the old behavior is desired, users can provide the appropriate mirrors via
apt:directives in cloud-config.
- cloudinit.features.ERROR_ON_USER_DATA_FAILURE = True
If there is a failure in obtaining user data (i.e., #include or decompress fails) and
False, cloud-init will log a warning and proceed. If it is
True, cloud-init will instead raise an exception.
As of 20.3,
(This flag can be removed after Focal is no longer supported.)