diff options
author | Stephen Finucane <sfinucan@redhat.com> | 2017-08-29 11:46:57 +0100 |
---|---|---|
committer | Stephen Finucane <sfinucan@redhat.com> | 2017-09-06 14:40:17 +0100 |
commit | 1eb53dfbcd6480691d8d3b80a6096c8be66560c5 (patch) | |
tree | 80181e848f9335c0339c0789e6d21260367f0609 /doc | |
parent | 67bc30b7e742b438894401084f0c957634e6f764 (diff) | |
download | nova-1eb53dfbcd6480691d8d3b80a6096c8be66560c5.tar.gz |
doc: Add user index page
The idea is that each guide should be self contained, even though we can
link between them. Enforce this by duplicating a lot of the content from
the main index page to the user index page.
Change-Id: I160fed0f1b507eba7958666bf38f4138b0f62b3a
Diffstat (limited to 'doc')
-rw-r--r-- | doc/source/index.rst | 1 | ||||
-rw-r--r-- | doc/source/user/index.rst | 75 |
2 files changed, 76 insertions, 0 deletions
diff --git a/doc/source/index.rst b/doc/source/index.rst index 3be81ad02f..1e3bbd4d94 100644 --- a/doc/source/index.rst +++ b/doc/source/index.rst @@ -268,6 +268,7 @@ looking parts of our architecture. These are collected below. reference/stable-api reference/threading reference/vm-states + user/index user/aggregates user/architecture user/block-device-mapping diff --git a/doc/source/user/index.rst b/doc/source/user/index.rst new file mode 100644 index 0000000000..ffc11414d6 --- /dev/null +++ b/doc/source/user/index.rst @@ -0,0 +1,75 @@ +================== +User Documentation +================== + +Architecture Overview +--------------------- + +* :doc:`Nova architecture </user/architecture>`: An overview of how all the parts in + nova fit together. + +* :doc:`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. + +* :doc:`Conductor </user/conductor>`: TODO + +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 :doc:`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. + + * :doc:`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). + + * :doc:`Feature Support full list </user/support-matrix>`: A detailed dive through + features in each compute driver backend. + +* :doc:`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. + +* :doc:`Placement service </user/placement>`: Overview of the placement + service, including how it fits in with the rest of nova. + +* :doc:`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. + +* :doc:`Admin Guide </admin/index>`: A collection of guides for administrating + nova. + + .. warning:: + + This guide was imported during the Pike cycle and is a bit out of + date. It will be updated during Queens to be more accurate. + +* :doc:`Upgrades </user/upgrade>`: How nova is designed to be upgraded for minimal + service impact, and the order you should do them in. + +* :doc:`Quotas </user/quotas>`: Managing project quotas in nova. + +* :doc:`Aggregates </user/aggregates>`: Aggregates are a useful way of grouping + hosts together for scheduling purposes. + +* :doc:`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. + +* :doc:`Exposing custom metadata to compute instances </user/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. |