Stephen Finucane 13b06ebb1c 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-10-19 12:51:39 +01:00

4.1 KiB

Raw Blame 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.

Internals

The following is a dive into some of the internals in nova.

/reference/rpc: How nova uses AMQP as an RPC transport
/reference/scheduling: The workflow through the scheduling process
/reference/scheduler-hints-vs-flavor-extra-specs: The similarities and differences between flavor extra specs and scheduler hints.
/reference/live-migration: The live migration flow
/reference/services: Module descriptions for some of the key modules used in starting / running services
/reference/vm-states: Cheat sheet for understanding the life cycle of compute instances
/reference/threading: The concurrency model used in nova, which is based on eventlet, and may not be familiar to everyone.
/reference/notifications: How the notifications subsystem works in nova, and considerations when adding notifications.
/reference/update-provider-tree: A detailed explanation of the ComputeDriver.update_provider_tree method.
/reference/upgrade-checks: A guide to writing automated upgrade checks.
/reference/database-migrations: A guide to writing database migrations, be they online or offline.
/reference/conductor

Need something about versioned objects and how they fit in with conductor as an object backporter during upgrades.

/reference/isolate-aggregates: Describes how the placement filter works in nova to isolate groups of hosts.
/reference/attach-volume: Describes the attach volume flow, using the libvirt virt driver as an example.
/reference/block-device-structs: Block Device Data Structures
/reference/libvirt-distro-support-matrix: Libvirt virt driver OS distribution support matrix

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

/reference/gmr: Inspired by Amiga, a way to trigger a very comprehensive dump of a running service for deep debugging.

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.

/reference/policy-enforcement: How we want policy checks on API actions to work in the future
/reference/stable-api: What stable API means to nova
/reference/scheduler-evolution: Motivation behind the scheduler / placement evolution

policy-enforcement stable-api scheduler-evolution

Additional Information

/reference/glossary: A quick reference guide to some of the terms you might encounter working on or using nova.

glossary

4.1 KiB Raw Blame History