121 lines
4.0 KiB
ReStructuredText
Raw Normal View History

================================
Technical Reference Deep Dives
================================
The nova project is large, and there are lots of complicated parts in it where
it helps to have an overview to understand how the internals of a particular
part work.
.. _reference-internals:
Internals
=========
The following is a dive into some of the internals in nova.
* :doc:`/reference/rpc`: How nova uses AMQP as an RPC transport
* :doc:`/reference/scheduling`: The workflow through the scheduling process
* :doc:`/reference/scheduler-hints-vs-flavor-extra-specs`: The similarities
and differences between flavor extra specs and scheduler hints.
* :doc:`/reference/live-migration`: The live migration flow
* :doc:`/reference/services`: Module descriptions for some of the key modules
used in starting / running services
* :doc:`/reference/vm-states`: Cheat sheet for understanding the life cycle of
compute instances
* :doc:`/reference/threading`: The concurrency model used in nova, which is
based on eventlet, and may not be familiar to everyone.
* :doc:`/reference/notifications`: The notifications available in nova.
* :doc:`/reference/update-provider-tree`: A detailed explanation of the
``ComputeDriver.update_provider_tree`` method.
* :doc:`/reference/upgrade-checks`: A guide to writing automated upgrade
checks.
* :doc:`/reference/database-migrations`: A guide to writing database
migrations, be they online or offline.
* :doc:`/reference/conductor`
.. todo:: Need something about versioned objects and how they fit in with
conductor as an object backporter during upgrades.
* :doc:`/reference/isolate-aggregates`: Describes how the placement filter
works in nova to isolate groups of hosts.
* :doc:`/reference/attach-volume`: Describes the attach volume flow, using the
libvirt virt driver as an example.
* :doc:`/reference/block-device-structs`: Block Device Data Structures
* :doc:`/reference/libvirt-distro-support-matrix`: Libvirt virt driver OS
distribution support matrix
.. # NOTE(amotoki): toctree needs to be placed at the end of the secion to
# keep the document structure in the PDF doc.
.. toctree::
:hidden:
rpc
scheduling
scheduler-hints-vs-flavor-extra-specs
live-migration
services
vm-states
threading
notifications
database-migrations
update-provider-tree
upgrade-checks
conductor
isolate-aggregates
api-microversion-history
attach-volume
block-device-structs
libvirt-distro-support-matrix
Debugging
=========
* :doc:`/reference/gmr`: Inspired by Amiga, a way to trigger a very
comprehensive dump of a running service for deep debugging.
.. # NOTE(amotoki): toctree needs to be placed at the end of the secion to
# keep the document structure in the PDF doc.
.. toctree::
:hidden:
gmr
Forward Looking 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 "Internals" 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.
* :doc:`/reference/policy-enforcement`: How we want policy checks on API actions
to work in the future
docs: Add a new cells v2 document We currently have three cells v2 documents in-tree: - A 'user/cellsv2-layout' document that details the structure or architecture of a cells v2 deployment (which is to say, any modern nova deployment) - A 'user/cells' document, which is written from a pre-cells v2 viewpoint and details the changes that cells v2 *will* require and the benefits it *would* bring. It also includes steps for upgrading from pre-cells v2 (that is, pre-Pike) deployment or a deployment with cells v1 (which we removed in Train and probably broke long before) - An 'admin/cells' document, which doesn't contain much other than some advice for handling down cells Clearly there's a lot of cruft to be cleared out as well as some centralization of information that's possible. As such, we combine all of these documents into one document, 'admin/cells'. This is chosen over 'users/cells' since cells are not an end-user-facing feature. References to cells v1 and details on upgrading from pre-cells v2 deployments are mostly dropped, as are some duplicated installation/configuration steps. Formatting is fixed and Sphinx-isms used to cross reference config option where possible. Finally, redirects are added so that people can continue to find the relevant resources. The result is (hopefully) a one stop shop for all things cells v2-related that operators can use to configure and understand their deployments. Change-Id: If39db50fd8b109a5a13dec70f8030f3663555065 Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
2021-07-09 17:58:52 +01:00
* :doc:`/reference/stable-api`: What stable API means to nova
* :doc:`/reference/scheduler-evolution`: Motivation behind the scheduler /
placement evolution
.. # NOTE(amotoki): toctree needs to be placed at the end of the secion to
# keep the document structure in the PDF doc.
.. toctree::
:hidden:
policy-enforcement
stable-api
scheduler-evolution
Additional Information
======================
* :doc:`/reference/glossary`: A quick reference guide to some of the terms you
might encounter working on or using nova.
.. # NOTE(amotoki): toctree needs to be placed at the end of the secion to
# keep the document structure in the PDF doc.
.. toctree::
:hidden:
glossary