If you would like to contribute to the development of OpenStack, you must follow the steps in this page:
If you already have a good understanding of how the system works and your OpenStack accounts are set up, you can skip to the development workflow section of this documentation to learn how changes to OpenStack should be submitted for review via the Gerrit tool:
Pull requests submitted through GitHub will be ignored.
Bugs should be filed on StoryBoard, not GitHub:
Either install bindep and run bindep test to check you have the needed tools, or review bindep.txt by hand.
The testing system is based on a combination of tox and testr. The canonical approach to running tests is to simply run the command tox. This will create virtual environments, populate them with dependencies and run all of the tests that OpenStack CI systems run. Behind the scenes, tox is running testr run –parallel, but is set up such that you can supply any additional testr arguments that are needed to tox. For example, you can run: tox – –analyze-isolation to cause tox to tell testr to add –analyze-isolation to its argument list.
It is also possible to run the tests inside of a virtual environment you have created, or it is possible that you have all of the dependencies installed locally already. If you’d like to go this route, the requirements are listed in requirements.txt and the requirements for testing are in test-requirements.txt. Installing them via pip, for instance, is simply:
pip install -r requirements.txt -r test-requirements.txt
In you go this route, you can interact with the testr command directly. Running testr run will run the entire test suite. testr run –parallel will run it in parallel (this is the default incantation tox uses.) More information about testr can be found at: http://wiki.openstack.org/testr
No internal API stability guarantees are made, but for reference here is a basic outline of the source implementation:
Project dependencies.
Return the rules active given profiles.
| Parameters: | profiles – A list of profiles to consider active. This should include platform profiles - they are not automatically included. |
|---|
Evaluate rules against the local environment.
| Parameters: | rules – A list of rules, as returned by active_rules. |
|---|---|
| Returns: | A list of unsatisfied rules. |
dpkg specific platform implementation.
This currently shells out to dpkg, it could in future use python-apt.
emerge specific implementation.
This currently shells out to equery, it could be changed to eix to be faster but that would add another dependency and eix’s cache would need to be updated before this is run.
pacman specific implementation.
This shells out to pacman
Interface for querying platform specific info.
Find the installed version of pkg_name.
| Returns: | None if pkg_name is not installed, or a version otherwise. |
|---|
rpm specific platform implementation.
This currently shells out to rpm, it could in future use rpm-python if that ever gets uploaded to PyPI.
The bindep utility is developed following a test-driven methodology. These are the current tests run to ensure its internal consistency for every commit:
Encapsulate running main().
| Attr logger: | The logger fixture from the process invocation. |
|---|---|
| Attr path: | The path to the root of the isolated temp dir. |