13b06ebb1c
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>
122 lines
4.1 KiB
ReStructuredText
122 lines
4.1 KiB
ReStructuredText
================================
|
|
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`: How the notifications subsystem works in
|
|
nova, and considerations when adding notifications.
|
|
* :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
|
|
* :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
|