nova/doc/source/development.environment.rst

183 lines
6.4 KiB
ReStructuredText
Raw Normal View History

2010-11-04 02:06:28 -04:00
..
Copyright 2010-2011 United States Government as represented by the
Administrator of the National Aeronautics and Space Administration.
2010-11-04 02:06:28 -04:00
All Rights Reserved.
Licensed under the Apache License, Version 2.0 (the "License"); you may
not use this file except in compliance with the License. You may obtain
a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
License for the specific language governing permissions and limitations
under the License.
=======================
Development Quickstart
=======================
2010-11-04 02:06:28 -04:00
This page describes how to setup and use a working Python development
environment that can be used in developing nova on Ubuntu, Fedora or
Mac OS X. These instructions assume you're already familiar with git.
Following these instructions will allow you to build the documentation
and run the nova unit tests. If you want to be able to run nova (i.e.,
launch VM instances), you will also need to --- either manually or by
letting DevStack do it for you --- install libvirt and at least one of
the `supported hypervisors`_. Running nova is currently only supported
on Linux, although you can run the unit tests on Mac OS X.
.. _supported hypervisors: http://wiki.openstack.org/HypervisorSupportMatrix
.. note:: For how to contribute to Nova, see
HowToContribute_.
Nova uses the Gerrit code review system, GerritWorkflow_.
.. _GerritWorkflow: http://docs.openstack.org/infra/manual/developers.html#development-workflow
.. _HowToContribute: http://docs.openstack.org/infra/manual/developers.html
.. _`docs.openstack.org`: http://docs.openstack.org
Setup
=====
There are two ways to create a development environment: using
DevStack, or explicitly installing and cloning just what you need.
Using DevStack
--------------
See `Devstack`_ Documentation. If you would like to use Vagrant, there is a `Vagrant`_ for DevStack.
.. _`Devstack`: http://docs.openstack.org/developer/devstack/
.. _`Vagrant`: https://github.com/openstack-dev/devstack-vagrant/blob/master/README.md
..
Until the vagrant markdown documents are rendered somewhere on .openstack.org, linking to github
Explicit Install/Clone
----------------------
DevStack installs a complete OpenStack environment. Alternatively,
you can explicitly install and clone just what you need for Nova
development.
The first step of this process is to install the system (not Python)
packages that are required. Following are instructions on how to do
this on Linux and on the Mac.
2010-11-23 12:49:28 -06:00
Linux Systems
`````````````
2010-11-23 12:49:28 -06:00
.. note::
This section is tested for Nova on Ubuntu (14.04-64) and
Fedora-based (RHEL 6.1) distributions. Feel free to add notes and
change according to your experiences or operating system.
2010-11-23 12:49:28 -06:00
Install the prerequisite packages.
2010-11-23 12:49:28 -06:00
On Ubuntu::
2010-11-23 12:49:28 -06:00
sudo apt-get install python-dev libssl-dev python-pip git-core libxml2-dev libxslt-dev pkg-config libffi-dev libpq-dev libmysqlclient-dev graphviz libsqlite3-dev python-tox python3-dev python3 gettext
On Fedora-based distributions (e.g., Fedora/RHEL/CentOS/Scientific Linux)::
2010-11-23 12:49:28 -06:00
sudo yum install python-devel openssl-devel python-pip git gcc libxslt-devel mysql-devel postgresql-devel libffi-devel libvirt-devel graphviz sqlite-devel python3-devel python3 gettext
sudo pip-python install tox
2010-11-23 12:58:08 -06:00
On openSUSE-based distributions (SLES 12, openSUSE Leap 42.1 or Tumbleweed)::
sudo zypper in gcc git libffi-devel libmysqlclient-devel libvirt-devel libxslt-devel postgresql-devel python-devel python-pip python-tox python-virtualenv python3-devel python3 gettext-runtime
Mac OS X Systems
````````````````
2010-11-23 12:49:28 -06:00
Install virtualenv::
2010-11-23 12:49:28 -06:00
sudo easy_install virtualenv
2010-11-23 12:49:28 -06:00
Check the version of OpenSSL you have installed::
2010-11-23 12:49:28 -06:00
openssl version
2010-11-23 12:49:28 -06:00
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) or Mac OS X 10.10.3 (OpenSSL 0.9.8zc) works
fine with nova. OpenSSL versions from brew like OpenSSL 1.0.1k work fine
as well.
2010-11-23 12:49:28 -06:00
Getting the code
````````````````
Once you have the prerequisite system packages installed, the next
step is to clone the code.
Grab the code from git::
2010-11-23 12:58:08 -06:00
git clone https://git.openstack.org/openstack/nova
2010-11-23 12:58:08 -06:00
cd nova
2010-11-23 12:49:28 -06:00
Building the Documentation
==========================
Set autodoc_index_modules=True so tox -e docs builds module docs again Commit bd7e62f796fe951fd42c2edad56e252a0b7393c8 disabled the autodoc_index_modules flag for building docs but it wasn't really necessary, that change was just to get the module index out of the main docs page. We want to autodoc the modules so we can view the actual module index in the tox -d docs build results, which also tells us if we have correct ReST format in doc strings. Notes ----- 1. Several doc string blocks have to be fixed as part of this to get the docs tox job to pass. 2. A docstring in vhdutilsv2 is updated to remove the math directive since that requires the sphinx.ext.pngmath extension which requires latex and dvipng packages from the distro - which is overkill for what the docstring was actually doing with the math directive. 3. We exclude autodoc for tests since we don't really care about docstrings on unit tests. 4. We exclude the nova.wsgi.nova-* modules since those won't build with autodoc since they can't be imported (there is no nova/wsgi/__init__.py module). We could arguably add the __init__.py but it's not really necessary for what those scripts are used for. 5. The sphinx.ext.ifconfig extension is removed since there are no docs that use the ifconfig directive. 6. Update the developer docs to explicitly point out that graphviz must be installed prior to running tox -e docs. 7. Hide doc/source/api/autoindex.rst from the toctree so that we don't regress the point of commit bd7e62f796fe951fd42c2edad56e252a0b7393c8. 8. unused_docs and exclude_trees options are removed from conf.py since they are deprecated in Sphinx 1.2.3: https://github.com/sphinx-doc/sphinx/blob/1.2.3/sphinx/config.py#L54 9. Fix imports for moved libvirt volume options. Closes-Bug: #1471934 Change-Id: I946e2f89f2c9fc70e870faaf84e4a8b0fc703344
2015-07-06 15:18:59 -07:00
Install the prerequisite packages: graphviz
To do a full documentation build, issue the following command while
the nova directory is current.
.. code-block:: bash
tox -edocs
That will create a Python virtual environment, install the needed
Python prerequisites in that environment, and build all the
documentation in that environment.
Running unit tests
==================
See `Running Python Unit Tests`_.
.. _`Running Python Unit Tests`: http://docs.openstack.org/infra/manual/python.html#running-python-unit-tests
Using a remote debugger
=======================
Some modern IDE such as pycharm (commercial) or Eclipse (open source) support remote debugging. In order to run nova with remote debugging, start the nova process
with the following parameters
--remote_debug-host <host IP where the debugger is running>
--remote_debug-port <port it is listening on>
Before you start your nova process, start the remote debugger using the instructions for that debugger.
For pycharm - http://blog.jetbrains.com/pycharm/2010/12/python-remote-debug-with-pycharm/
For Eclipse - http://pydev.org/manual_adv_remote_debugger.html
More detailed instructions are located here - http://novaremotedebug.blogspot.com
Using fake computes for tests
=============================
The number of instances supported by fake computes is not limited by physical
constraints. It allows you to perform stress tests on a deployment with few
resources (typically a laptop). But you must avoid using scheduler filters
limiting the number of instances per compute (like RamFilter, DiskFilter,
AggregateCoreFilter), otherwise they will limit the number of instances per
compute.
Fake computes can also be used in multi hypervisor-type deployments in order to
take advantage of fake and "real" computes during tests:
* create many fake instances for stress tests
* create some "real" instances for functional tests
Fake computes can be used for testing Nova itself but also applications on top
of it.