Files
nova/doc/source/user/index.rst
Akihiro Motoki 152d5c359c doc: Improve PDF document structure
This is a follow-up patch for https://review.opendev.org/676730.

In the TOC of the current PDF file [1], most contents related to
user and admin guides are located under "For Contributors" section.
This is weird. It happens because the latex builder constructs
the document tree based on "toctree" directives even though they
are marked as "hidden".

This commit reorganizes "toctree" per section.
The "toctree" directives must be placed at the end of
individual sections. Otherwise, content of a last section and
content just after "toctree" directive are concatenated
into a same section in the rendered LaTeX document.

This commit also improves the following as well:

* Specify "openany" as "extraclassoptions" to skip blank pages
  along with "oneside" to use same page style for odd and even pages.
* Set "tocdepth" and "secnumdepth" to 3 respectively.
  "tocdepth" controls the depth of TOC and "secnumdepth" controls
  the level of numbered sections in TOC.

Note that this commit does not reorganize file structure under doc/source.
I believe this should be done separately.

[1] https://docs.openstack.org/nova/latest/doc-nova.pdf

Change-Id: Ie9685e6a4798357d4979aa6b4ff8a03663a9c71c
Story: 2006100
Task: 35140
2019-10-08 11:06:00 +01:00

3.5 KiB

User Documentation

End user guide

launch-instances metadata manage-ip-addresses certificate-validation resize reboot availability-zones block-device-mapping /reference/api-microversion-history

The rest of this document should probably move to the admin guide.

Architecture Overview

  • Nova architecture </user/architecture>: An overview of how all the parts in nova fit together.
  • Block Device Mapping </user/block-device-mapping>: One of the more complicated parts to understand is the Block Device Mapping parameters used to connect specific block devices to computes. This deserves its own deep dive.

See the reference guide <reference-internals> for details about more internal subsystems.

Deployment Considerations

There is information you might want to consider before doing your deployment, especially if it is going to be a larger deployment. For smaller deployments the defaults from the install guide </install/index> will be sufficient.

  • Compute Driver Features Supported: While the majority of nova deployments use libvirt/kvm, you can use nova with other compute drivers. Nova attempts to provide a unified feature set across these, however, not all features are implemented on all backends, and not all features are equally well tested.
    • Feature Support by Use Case </user/feature-classification>: A view of what features each driver supports based on what's important to some large use cases (General Purpose Cloud, NFV Cloud, HPC Cloud).
    • Feature Support full list </user/support-matrix>: A detailed dive through features in each compute driver backend.
  • Cells v2 Planning </user/cellsv2-layout>: For large deployments, Cells v2 allows sharding of your compute environment. Upfront planning is key to a successful Cells v2 layout.
  • Placement service <>: Overview of the placement service, including how it fits in with the rest of nova.
  • Running nova-api on wsgi </user/wsgi>: Considerations for using a real WSGI container instead of the baked-in eventlet web server.

Maintenance

Once you are running nova, the following information is extremely useful.

  • Admin Guide </admin/index>: A collection of guides for administrating nova.
  • Upgrades </user/upgrade>: How nova is designed to be upgraded for minimal service impact, and the order you should do them in.
  • Quotas </user/quotas>: Managing project quotas in nova.
  • Availablity Zones </admin/availability-zones>: Availability Zones are an end-user visible logical abstraction for partitioning a cloud without knowing the physical infrastructure. They can be used to partition a cloud on arbitrary factors, such as location (country, datacenter, rack), network layout and/or power source.
  • Filter Scheduler </user/filter-scheduler>: How the filter scheduler is configured, and how that will impact where compute instances land in your environment. If you are seeing unexpected distribution of compute instances in your hosts, you'll want to dive into this configuration.
  • Exposing custom metadata to compute instances </admin/vendordata>: How and when you might want to extend the basic metadata exposed to compute instances (either via metadata server or config drive) for your specific purposes.