229 lines
6.5 KiB
ReStructuredText
229 lines
6.5 KiB
ReStructuredText
..
|
|
Copyright 2010-2012 United States Government as represented by the
|
|
Administrator of the National Aeronautics and Space Administration.
|
|
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.
|
|
|
|
==========================================
|
|
Welcome to Nova's developer documentation!
|
|
==========================================
|
|
|
|
Nova is an OpenStack project designed to provide power massively scalable, on
|
|
demand, self service access to compute resources.
|
|
|
|
The developer documentation provided here is continually kept up-to-date
|
|
based on the latest code, and may not represent the state of the project at
|
|
any specific prior release.
|
|
|
|
.. note:: This is documentation for developers, if you are looking for more
|
|
general documentation including API, install, operator and user
|
|
guides see `docs.openstack.org`_
|
|
|
|
.. _`docs.openstack.org`: http://docs.openstack.org
|
|
|
|
This documentation is intended to help explain what the Nova developers think
|
|
is the current scope of the Nova project, as well as the architectural
|
|
decisions we have made in order to support that scope. We also document our
|
|
plans for evolving our architecture over time. Finally, we documented our
|
|
current development process and policies.
|
|
|
|
Compute API References
|
|
======================
|
|
|
|
The Nova compute API is quite large, we provide a concept guide which
|
|
gives some of the high level details, as well as a more detailed API
|
|
reference.
|
|
|
|
The API reference covers all versions of the API. Version 2.0 and
|
|
Version 2.1 are actually the same API, and Version 2.1 evolves forward
|
|
with microversions. The API ref starts with the base API version, and
|
|
specifies all changes that exist to it as microversions roll
|
|
forward. You can also see a history of our microversions here:
|
|
|
|
.. toctree::
|
|
:maxdepth: 1
|
|
|
|
api_microversion_history
|
|
|
|
|
|
.. _`Compute API Guide`: http://developer.openstack.org/api-guide/compute/
|
|
.. _`Compute API Reference`: http://developer.openstack.org/api-ref/compute/
|
|
|
|
There was a session on the v2.1 API at the Liberty summit which you can watch
|
|
`here <https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/introduction-of-a-new-nova-rest-api-why-we-need-to-use-nova-v2-1-api>`_.
|
|
|
|
|
|
Feature Status
|
|
==============
|
|
|
|
Nova aims to have a single compute API that works the same across
|
|
all deployments of Nova.
|
|
While many features are well-tested, well-documented, support live upgrade,
|
|
and are ready for production, some are not. Also the choice of underlying
|
|
technology affects the list of features that are ready for production.
|
|
|
|
Our first attempt to communicate this is the feature support matrix
|
|
(previously called the hypervisor support matrix).
|
|
Over time we hope to evolve that to include a classification of each feature's
|
|
maturity and exactly what technology combinations are covered by current
|
|
integration testing efforts.
|
|
|
|
.. toctree::
|
|
:maxdepth: 1
|
|
|
|
test_strategy
|
|
feature_classification
|
|
support-matrix
|
|
|
|
Developer Guide
|
|
===============
|
|
|
|
If you are new to Nova, this should help you start to understand what Nova
|
|
actually does, and why.
|
|
|
|
.. toctree::
|
|
:maxdepth: 1
|
|
|
|
how_to_get_involved
|
|
process
|
|
architecture
|
|
project_scope
|
|
development.environment
|
|
|
|
Development Policies
|
|
--------------------
|
|
|
|
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 engage in that debate, 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 good communication between all members of the Nova
|
|
community, while keeping users happy and keeping developers productive.
|
|
|
|
.. toctree::
|
|
:maxdepth: 1
|
|
|
|
process
|
|
blueprints
|
|
policies
|
|
|
|
Architecture Concepts
|
|
----------------------
|
|
|
|
This follows on for the discussion in the introduction, and digs into
|
|
details on specific parts of the Nova architecture.
|
|
|
|
We find it important to document the reasons behind our architectural
|
|
decisions, so its easier for people to engage in the debates about
|
|
the future of Nova's architecture. This is all part of Open Design and
|
|
Open Development.
|
|
|
|
.. toctree::
|
|
:maxdepth: 1
|
|
|
|
aggregates
|
|
threading
|
|
vmstates
|
|
i18n
|
|
filter_scheduler
|
|
rpc
|
|
block_device_mapping
|
|
addmethod.openstackapi
|
|
conductor
|
|
notifications
|
|
|
|
Architecture Evolution Plans
|
|
-----------------------------
|
|
|
|
The following section includes documents that describe the overall plan behind
|
|
groups of nova-specs. Most of these cover items relating to the evolution of
|
|
various parts of Nova's architecture. Once the work is complete,
|
|
these documents will move into the "Concepts" section.
|
|
If you want to get involved in shaping the future of Nova's architecture,
|
|
these are a great place to start reading up on the current plans.
|
|
|
|
.. toctree::
|
|
:maxdepth: 1
|
|
|
|
cells
|
|
upgrade
|
|
api_plugins
|
|
api_microversion_dev
|
|
policy_enforcement
|
|
stable_api
|
|
code-review
|
|
scheduler_evolution
|
|
|
|
Advanced testing and guides
|
|
----------------------------
|
|
|
|
.. toctree::
|
|
:maxdepth: 1
|
|
|
|
gmr
|
|
testing/libvirt-numa
|
|
testing/serial-console
|
|
|
|
Sample Configuration File
|
|
-------------------------
|
|
|
|
.. toctree::
|
|
:maxdepth: 1
|
|
|
|
sample_config
|
|
|
|
|
|
Man Pages
|
|
----------
|
|
|
|
.. toctree::
|
|
:maxdepth: 1
|
|
|
|
man/index
|
|
|
|
Module Reference
|
|
----------------
|
|
.. toctree::
|
|
:maxdepth: 1
|
|
|
|
services
|
|
|
|
|
|
.. # NOTE(mriedem): This is the section where we hide things that we don't
|
|
# actually want in the table of contents but sphinx build would fail if
|
|
# they aren't in the toctree somewhere. For example, we hide api/autoindex
|
|
# since that's already covered with modindex below.
|
|
.. toctree::
|
|
:hidden:
|
|
|
|
Metadata
|
|
========
|
|
|
|
.. toctree::
|
|
:maxdepth: 1
|
|
|
|
vendordata
|
|
|
|
Indices and tables
|
|
==================
|
|
|
|
* :ref:`search`
|