37164b418e
The conductor doc is not really end user material, so this moves it under reference/, removes it from the user page and adds it to the reference index for internals. Also makes the contributor page link to the reference internals since it's kind of weird to have one contributor section that only mentions one thing but the internals under reference have a lot more of that kind of detail. Finally, a todo is added so we don't forget to update the reference internals about versioned objects at some point since that's always a point of confusion for people. Change-Id: I8d3dbce5334afaa3e1ca309b2669eff9933a0104
3.2 KiB
3.2 KiB
User Documentation
End user guide
launch-instances metadata certificate-validation resize reboot
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.Aggregates </user/aggregates>: Aggregates are a useful way of grouping hosts together for scheduling purposes.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.