How to Contribute to Code Development

The contribution and feedback from our User Community is fundamental to the OpenNebula project. There are several ways to contribute to OpenNebula.

  • Please read the Add-ons Catalog page if you are interested in creating a new Add-on or contributing to one of the Add-ons.
  • OpenNebula source code is available at GitHub. We use GitHub issues to track bugs and feature requests coming from the community. If you haven’t already, create a GitHub account and subscribe to the Community Forum. It is assumed that you’re willing to contribute new code or documentation under the Apache License 2.0.

Thanks for making OpenNebula a better project!

How Do I Report a Bug?

You can report a bug by opening a new issue in GitHub OpenNebula project. You have to complete the template section for bug reports. Be sure to specify all sections:

  • Version of OpenNebula
  • Component
  • Brief description
  • Expected behavior
  • How to reproduce

After an internal analysis, a bug issue will be set to one of the following statuses:

  • Pending: needs to be verified
  • Accepted: the bug has been verified and a priority assigned based on its severity (Low, Normal, High)
  • Planned: (Accepted with a specific milestone)
  • Closed: the issue is fixed, could not be reproduced (worksforme) or duplicates another one

How Do I Make a Feature Request?

You can make a feature request by opening a new issue in the GitHub OpenNebula project. Be sure to specify all sections in the template:

  • Brief description of the new functionality
  • How are you going to use this new feature? Why do you need it?
  • Describe any changes to current interfaces including Sunstone, CLI and/or API

The issue will be used to track the discussions about the new feature. You should also specify if you are planing to allocate resources to implement the new feature. Once the new issue is created, you can bring it up for discussion on the Community Forum.

We will contact you as soon as possible to gather more information and to give you initial feedback about your Request issue. This may take some time, and is usually not done until the next release cycle, at the earliest. When we update the roadmap of the project and plan the features for the next release, we prioritize:

  • The features demanded by the projects and organizations sponsoring the open-source project
  • The most demanded features by the community

After an internal analysis, your Request issue is categorized and will be Pending in the Backlog until:

  • It is interesting for the OpenNebula community and will be added as Accepted in the Backlog
  • It is decided that is not in the scope of the project and Closed

Backlog issues are long-medium term roadmap features to be implemented in OpenNebula. The priority of the issues will be graded (Low, Normal, High). A backlog issue remains Accepted until:

  • It is assigned to a Milestone and so moved to the Feature list
  • It is Closed because it is no longer interesting for the OpenNebula Community

Feature issues are short term Accepted features with an assigned milestone.

How Can I Contribute Bug and Feature Patches?

You can use the GitHub Pull Request model to submit a bug or feature patch.

  • Fork it
  • Create a branch (git checkout -b my_markup)
  • Commit your changes (git commit -am “My changes”)
  • Push to the branch (git push origin my_markup)
  • Create a Pull Request to this repository from your new branch

It is understood that your patch addresses an open issue in GitHub. Update the issue with a full description of what you have done, describe your tests, and include a link to the Pull Request. When your patch is reviewed, it may be accepted “as-is” or you may be asked to make changes. Code commits (after review) will be implemented as named commits.

How Can I Contribute New Functional Components?

Before entering a new issue following the Feature Request process, first check if there is already an open issue addressing a similar feature. Describe your work plan and the resources you are planning to allocate in the issue. Then you should bring it up for discussion on the Community Forum. Other developers may have suggestions, and this ensures that the new feature is aligned with the roadmap and other features being developed. It is important to be sure that you’re not doing redundant work.

New features can be:

  • Enhancements in the OpenNebula core distribution. These should be contributed by following the process to contribute feature patches.
  • New interfaces and drivers that extend platform support. New tools, interfaces and drivers that broaden the platform technologies and services with which OpenNebula can interface are published on the Add-ons catalog. These may be incorporated into the main OpenNebula distribution after an incubation process. Visit our Add-on section for more information about how to contribute new Add-ons or contribute to an existing Add-on

What Are Our Design Principles?

The OpenNebula technology is the result of many years of research and development in efficient and scalable management of virtual machines on large-scale distributed infrastructures. OpenNebula was designed to address the requirements of business use cases from leading companies and across multiple industries, such as Hosting, Telecom, eGovernment, Utility Computing… The main principles of OpenNebula’s design are:

  • Openness of the architecture, interfaces, and code
  • Flexibility to fit into any data center
  • Interoperability and portability to prevent vendor lock-in
  • Stability for use in production enterprise-class environments
  • Scalability for large scale infrastructures
  • SysAdmin-focus with complete control over the cloud
  • Simplicity, easy to deploy, operate and use
  • Lightness for high efficiency

Licensing and Copyright

OpenNebula is fully open-source software distributed and licensed for use under the terms of the Apache License, Version 2.0.

You must sign your work before we can contribute it to OpenNebula. Pull Requests with commits that do not contain a “signed-off” by the author will not be accepted.