Hacking on 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
Do these things once¶
To contribute, 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 ‘Josh Powers’.
- 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 Josh Powers with the subject, “Cloud-Init CLA”
- You also may contact user
#cloud-initchannel on the Freenode 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 firstname.lastname@example.org:GH_USER/cloud-init.git git push GH_USER master
Read through the cloud-init Code Review Process, so you understand how your changes will end up in cloud-init’s codebase.
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.
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.):
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 merge 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 74 characters followed by a blank line, and then one or more paragraphs 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 trunk. LP: #1
Note that the project continues to use LP: #NNNNN format for closing launchpad bugs rather than GitHub Issues.
Click ‘Create Pull Request`
Feel free to ping and/or join
#cloud-init on freenode irc if you
have any questions.
This section captures design decisions that are helpful to know when hacking on cloud-init.
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).
cloud-init uses pytest to run its tests, and has tests written both
unittest.TestCase sub-classes and as un-subclassed pytest tests.
The following guidelines should be following:
- For ease of organisation and greater accessibility for developers not
familiar with pytest, all cloud-init unit tests must be contained
within test classes
- Put another way, module-level test functions should not be used
- pytest test classes should use pytest fixtures to share functionality instead of inheritance
- As all tests are contained within classes, it is acceptable to mix
TestCasetest classes and pytest test classes within the same test file
- pytest tests should use bare
assertstatements, to take advantage of pytest’s assertion introspection
==and other commutative assertions, the expected value should be placed before the value under test:
assert expected_value == function_under_test()
The cloud-init codebase uses Python’s annotation support for storing
type annotations in the style specified by PEP-484. Their use in
the codebase is encouraged but with one important caveat: types from
typing module cannot be used.
cloud-init still supports Python 3.4, which doesn’t have the
module in the stdlib. This means that the use of any types from the
typing module in the codebase would require installation of an
additional Python module on platforms using Python 3.4. As such
platforms are generally in maintenance mode, the introduction of a new
dependency may act as a break in compatibility in practical terms.
Similarly, only function annotations are appropriate for use, as the variable annotations specified in PEP-526 were introduced in Python 3.6.