Contributor Documentation

Contributing to nova gives you the power to help add features, fix bugs, enhance documentation, and increase testing. Contributions of any type are valuable, and part of what keeps the project going. Here are a list of resources to get your started.

Basic Information

Getting Started

Nova Process

The nova community is a large community. We have lots of users, and they all have a lot of expectations around upgrade and backwards compatibility. For example, having a good stable API, with discoverable versions and capabilities is important for maintaining the strong ecosystem around nova.

Our process is always evolving, just as nova and the community around nova evolves over time. If there are things that seem strange, or you have ideas on how to improve things, please bring them forward on IRC or the openstack-discuss mailing list, so we continue to improve how the nova community operates.

This section looks at the processes and why. The main aim behind all the process is to aid communication between all members of the nova community, while keeping users happy and keeping developers productive.

Code Conventions

  • OpenStack code and documentation guide: General OpenStack contributor conventions covering style, testing, and documentation standards.

  • Nova HACKING.rst: Nova-specific style rules and N-check descriptions; enforced by tox -e pep8.

  • Dependencies: Where to declare Python, documentation, and system package dependencies.

  • Commit Messages: Nova commit message guidance, including Gerrit footers, DCO sign-off, and AI attribution trailers.

  • Release Notes: When we need a release note for a contribution.

  • Internationalization: What we require for i18n in patches.

  • Database migrations: How to write schema and data migrations when adding a feature or bugfix.

  • Upgrade checks: How to write automated upgrade checks when adding a feature or bugfix.

Reviewing

  • Code Review Guide for Nova: Important cheat sheet for what’s important when doing code review in Nova, especially some things that are hard to test for, but need human eyes.

  • Documentation Guidelines: Guidelines for handling documentation contributions

Testing

Because Python is a dynamic language, code that is not tested might not even be Python code. All new code needs to be validated somehow.

The Nova API

Because we have many consumers of our API, we’re extremely careful about changes done to the API, as the impact can be very wide.

Nova also provides notifications over the RPC API, which you may wish to extend.

Nova Major Subsystems

Major subsystems in nova have different needs. If you are contributing to one of these please read the reference guide before diving in.

  • Move operations

    • Evacuate vs Rebuild: Describes the differences between the often-confused evacuate and rebuild operations.

    • Resize and cold migrate: Describes the differences and similarities between resize and cold migrate operations.