Alembic does lots of new things. Provide docs for how to use this. We also improve upgrade docs slightly, removing references to ancient reviews that are no longer really helpful as well as calling out our N -> N+1 constraint. Change-Id: I3760b82ce3bd71aa0a760d7137d69dfa3f29dc1d Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
124 lines
4.1 KiB
ReStructuredText
124 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:`/user/cells`: How cells v2 is evolving
|
|
* :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:
|
|
|
|
/user/cells
|
|
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
|