"Fossies" - the Fresh Open Source Software Archive

Member "manila-11.0.1/doc/source/contributor/development.environment.rst" (1 Feb 2021, 5716 Bytes) of package /linux/misc/openstack/manila-11.0.1.tar.gz:

As a special service "Fossies" has tried to format the requested source page into HTML format (assuming markdown format). Alternatively you can here view or download the uninterpreted source code file. A member file download can also be achieved by clicking within a package contents listing on the according byte size field. See also the latest Fossies "Diffs" side-by-side code changes report for "development.environment.rst": 11.0.0_vs_11.0.1.

Setting Up a Development Environment

This page describes how to setup a working Python development environment that can be used in developing manila on Ubuntu, Fedora or Mac OS X. These instructions assume you're already familiar with git. Refer to Getting the code for additional information.

Following these instructions will allow you to run the manila unit tests. If you want to be able to run manila (i.e., create NFS/CIFS shares), you will also need to install dependent projects: nova, neutron, cinder and glance. For this purpose 'devstack' project can be used (A documented shell script to build complete OpenStack development environments). You can check out Setting up a development environment with devstack for instructions on how to enable manila on devstack.

Virtual environments

Manila development uses virtualenv to track and manage Python dependencies while in development and testing. This allows you to install all of the Python package dependencies in a virtual environment or "virtualenv" (a special subdirectory of your manila directory), instead of installing the packages at the system level.


Virtualenv is useful for running the unit tests, but is not typically used for full integration testing or production usage.

Linux Systems


This section is tested for manila on Ubuntu and Fedora-based distributions. Feel free to add notes and change according to your experiences or operating system.

Install the prerequisite packages.


If using RHEL and yum reports "No package python3-pip available" and "No package git-review available", use the EPEL software repository. Instructions can be found at http://fedoraproject.org/wiki/EPEL/FAQ#howtouse.


Additionally, if using Fedora 23, redhat-rpm-config package should be installed so that development virtualenv can be built successfully.

Mac OS X Systems

Install virtualenv:

sudo easy_install virtualenv

Check the version of OpenSSL you have installed:

openssl version

If you have installed OpenSSL 1.0.0a, which can happen when installing a MacPorts package for OpenSSL, you will see an error when running manila.tests.auth_unittest.AuthTestCase.test_209_can_generate_x509.

The stock version of OpenSSL that ships with Mac OS X 10.6 (OpenSSL 0.9.8l) or Mac OS X 10.7 (OpenSSL 0.9.8r) works fine with manila.

Getting the code

Grab the code:

git clone https://opendev.org/openstack/manila
cd manila

Running unit tests

The preferred way to run the unit tests is using tox. Tox executes tests in isolated environment, by creating separate virtualenv and installing dependencies from the requirements.txt and test-requirements.txt files, so the only package you install is tox itself:

sudo pip install tox

Run the unit tests with:

tox -e py{python-version}


tox -epy36

See unit_tests for more details.

Manually installing and using the virtualenv

You can also manually install the virtual environment:

tox -epy36 --notest

This will install all of the Python packages listed in the requirements.txt file into your virtualenv.

To activate the Manila virtualenv you can run:

$ source .tox/py36/bin/activate

To exit your virtualenv, just type:

$ deactivate

Or, if you prefer, you can run commands in the virtualenv on a case by case basis by running:

$ tox -e venv -- <your command>

Contributing Your Work

Once your work is complete you may wish to contribute it to the project. Manila uses the Gerrit code review system. For information on how to submit your branch to Gerrit, see GerritWorkflow.