This provides a brief explanation of the new nova-api-wsgi [1] and nova-metadata-wsgi [2] scripts in the Architecture section of the devref with links to the new doc added to the man pages for the eventlet scripts. The nova-api.rst mentioned ec2 so figured best to fix that now rather than forget about it, despite not being entirely germane. There is also a reno note that indicates the availability of the new scripts. There is a devstack change which is testing the new wsgi scripts as well as forcing grenade to not use them at If2d7e363a6541854f2e30c03171bef7a41aff745 [1] I7c4acfaa6c50ac0e4d6de69eb62ec5bbad72ff85 [2] Icb35fe2b94ab02c0ba8ba8129ae18aae0f794756 Change-Id: I351b2af3b256d3031bd2a65feba0495e815f8427 Related-Bug: #1661360
6.9 KiB
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
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:
api_microversion_history
Note
Only Version 2.1 APIs should be used from this point forward, Version 2.0 APIs are only provided for backward compatibility purposes.
There was a session on the v2.1 API at the Liberty summit which you can watch here.
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.
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.
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.
process blueprints policies code-review releasenotes
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.
addmethod.openstackapi rpc block_device_mapping conductor filter_scheduler aggregates i18n notifications placement placement_dev quotas threading vmstates wsgi
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.
cells upgrade api_plugins api_microversion_dev policy_enforcement stable_api scheduler_evolution
Advanced testing and guides
gmr testing/libvirt-numa testing/serial-console testing/zero-downtime-upgrade
Sample Configuration File
sample_config
Sample Policy file
sample_policy
Man Pages
man/index
Module Reference
services
Metadata
vendordata
Indices and tables
search