docs: Remove 'adv-config', 'system-admin' subdocs

These made things significantly less discoverable from the admin guide
and resulted in some duplication of links. Better to just flatten
things. Things are pretty much copy-pasted save for the removal of a
reference to the long-dead nova-objectstore service and the addition of
a TODO to provide overviews of other services.

Change-Id: Ibf2b6979318cf3f0a0519f66acbc279b2ce80968
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
This commit is contained in:
Stephen Finucane 2019-09-24 17:38:54 +01:00
parent c5d094ad3d
commit da207cc2be
5 changed files with 124 additions and 133 deletions

View File

@ -74,3 +74,5 @@ redirectmatch 301 ^/nova/([^/]+)/user/vendordata.html$ /nova/$1/user/metadata.ht
redirectmatch 301 ^/nova/([^/]+)/vendordata.html$ /nova/$1/user/metadata.html
redirectmatch 301 ^/nova/([^/]+)/vmstates.html$ /nova/$1/reference/vm-states.html
redirectmatch 301 ^/nova/([^/]+)/wsgi.html$ /nova/$1/user/wsgi.html
redirectmatch 301 ^/nova/([^/]+)/admin/adv-config.html$ /nova/$1/admin/index.html
redirectmatch 301 ^/nova/([^/]+)/admin/system-admin.html$ /nova/$1/admin/index.html

View File

@ -1,34 +0,0 @@
======================
Advanced configuration
======================
OpenStack clouds run on platforms that differ greatly in the capabilities that
they provide. By default, the Compute service seeks to abstract the underlying
hardware that it runs on, rather than exposing specifics about the underlying
host platforms. This abstraction manifests itself in many ways. For example,
rather than exposing the types and topologies of CPUs running on hosts, the
service exposes a number of generic CPUs (virtual CPUs, or vCPUs) and allows
for overcommitting of these. In a similar manner, rather than exposing the
individual types of network devices available on hosts, generic
software-powered network ports are provided. These features are designed to
allow high resource utilization and allows the service to provide a generic
cost-effective and highly scalable cloud upon which to build applications.
This abstraction is beneficial for most workloads. However, there are some
workloads where determinism and per-instance performance are important, if not
vital. In these cases, instances can be expected to deliver near-native
performance. The Compute service provides features to improve individual
instance for these kind of workloads.
.. include:: /common/numa-live-migration-warning.txt
.. toctree::
:maxdepth: 2
pci-passthrough
cpu-topologies
huge-pages
virtual-gpu
file-backed-memory
port_with_resource_request
virtual-persistent-memory

View File

@ -11,6 +11,126 @@ Compute does not include virtualization software. Instead, it defines drivers
that interact with underlying virtualization mechanisms that run on your host
operating system, and exposes functionality over a web-based API.
Overview
--------
To effectively administer compute, you must understand how the different
installed nodes interact with each other. Compute can be installed in many
different ways using multiple servers, but generally multiple compute nodes
control the virtual servers and a cloud controller node contains the remaining
Compute services.
The Compute cloud works using a series of daemon processes named ``nova-*``
that exist persistently on the host machine. These binaries can all run on the
same machine or be spread out on multiple boxes in a large deployment. The
responsibilities of services and drivers are:
.. rubric:: Services
``nova-api``
Receives XML requests and sends them to the rest of the system. A WSGI app
routes and authenticates requests. Supports the OpenStack Compute APIs. A
``nova.conf`` configuration file is created when Compute is installed.
.. todo::
Describe nova-api-metadata, nova-api-os-compute, nova-serialproxy and
nova-spicehtml5proxy
nova-console, nova-dhcpbridge and nova-xvpvncproxy are all deprecated for
removal so they can be ignored.
``nova-compute``
Manages virtual machines. Loads a Service object, and exposes the public
methods on ComputeManager through a Remote Procedure Call (RPC).
``nova-conductor``
Provides database-access support for compute nodes (thereby reducing security
risks).
``nova-network``
Manages floating and fixed IPs, DHCP, bridging and VLANs. Loads a Service
object which exposes the public methods on one of the subclasses of
NetworkManager. Different networking strategies are available by changing the
``network_manager`` configuration option to ``FlatManager``,
``FlatDHCPManager``, or ``VLANManager`` (defaults to ``VLANManager`` if
nothing is specified).
.. deprecated:: 14.0.0
``nova-network`` was deprecated in the OpenStack Newton release.
``nova-scheduler``
Dispatches requests for new virtual machines to the correct node.
``nova-novncproxy``
Provides a VNC proxy for browsers, allowing VNC consoles to access virtual
machines.
.. note::
Some services have drivers that change how the service implements its core
functionality. For example, the ``nova-compute`` service supports drivers
that let you choose which hypervisor type it can use. ``nova-network`` and
``nova-scheduler`` also have drivers.
.. toctree::
:maxdepth: 2
manage-users.rst
manage-volumes.rst
flavors.rst
default-ports.rst
admin-password-injection.rst
manage-the-cloud.rst
manage-logs.rst
root-wrap-reference.rst
configuring-migrations.rst
live-migration-usage.rst
remote-console-access.rst
service-groups.rst
node-down.rst
Advanced configuration
----------------------
OpenStack clouds run on platforms that differ greatly in the capabilities that
they provide. By default, the Compute service seeks to abstract the underlying
hardware that it runs on, rather than exposing specifics about the underlying
host platforms. This abstraction manifests itself in many ways. For example,
rather than exposing the types and topologies of CPUs running on hosts, the
service exposes a number of generic CPUs (virtual CPUs, or vCPUs) and allows
for overcommitting of these. In a similar manner, rather than exposing the
individual types of network devices available on hosts, generic
software-powered network ports are provided. These features are designed to
allow high resource utilization and allows the service to provide a generic
cost-effective and highly scalable cloud upon which to build applications.
This abstraction is beneficial for most workloads. However, there are some
workloads where determinism and per-instance performance are important, if not
vital. In these cases, instances can be expected to deliver near-native
performance. The Compute service provides features to improve individual
instance for these kind of workloads.
.. include:: /common/numa-live-migration-warning.txt
.. toctree::
:maxdepth: 2
pci-passthrough
cpu-topologies
huge-pages
virtual-gpu
file-backed-memory
port_with_resource_request
virtual-persistent-memory
Additional guides
-----------------
.. TODO(mriedem): This index page has a lot of content which should be
organized into groups for things like configuration, operations,
troubleshooting, etc.
@ -18,44 +138,26 @@ operating system, and exposes functionality over a web-based API.
.. toctree::
:maxdepth: 2
admin-password-injection.rst
adv-config.rst
aggregates
arch.rst
availability-zones.rst
cells.rst
config-drive.rst
configuration/index.rst
configuring-migrations.rst
cpu-topologies.rst
default-ports.rst
evacuate.rst
flavors.rst
huge-pages.rst
image-caching.rst
live-migration-usage.rst
manage-logs.rst
manage-the-cloud.rst
manage-users.rst
manage-volumes.rst
metadata-service.rst
migration.rst
migrate-instance-with-snapshot.rst
networking-nova.rst
networking.rst
node-down.rst
pci-passthrough.rst
quotas2.rst
quotas.rst
remote-console-access.rst
root-wrap-reference.rst
security-groups.rst
security.rst
service-groups.rst
services.rst
ssh-configuration.rst
support-compute.rst
system-admin.rst
secure-live-migration-with-qemu-native-tls.rst
mitigation-for-Intel-MDS-security-flaws.rst
vendordata.rst

View File

@ -1,81 +0,0 @@
.. _compute-trusted-pools.rst:
=====================
System administration
=====================
.. toctree::
:maxdepth: 2
manage-users.rst
manage-volumes.rst
flavors.rst
default-ports.rst
admin-password-injection.rst
manage-the-cloud.rst
manage-logs.rst
root-wrap-reference.rst
configuring-migrations.rst
live-migration-usage.rst
remote-console-access.rst
service-groups.rst
node-down.rst
adv-config.rst
To effectively administer compute, you must understand how the different
installed nodes interact with each other. Compute can be installed in many
different ways using multiple servers, but generally multiple compute nodes
control the virtual servers and a cloud controller node contains the remaining
Compute services.
The Compute cloud works using a series of daemon processes named ``nova-*``
that exist persistently on the host machine. These binaries can all run on the
same machine or be spread out on multiple boxes in a large deployment. The
responsibilities of services and drivers are:
**Services**
``nova-api``
Receives XML requests and sends them to the rest of the system. A WSGI app
routes and authenticates requests. Supports the OpenStack Compute APIs. A
``nova.conf`` configuration file is created when Compute is installed.
``nova-compute``
Manages virtual machines. Loads a Service object, and exposes the public
methods on ComputeManager through a Remote Procedure Call (RPC).
``nova-conductor``
Provides database-access support for compute nodes (thereby reducing security
risks).
``nova-objectstore``
A simple file-based storage system for images that replicates most of the S3
API. It can be replaced with OpenStack Image service and either a simple
image manager or OpenStack Object Storage as the virtual machine image
storage facility. It must exist on the same node as ``nova-compute``.
``nova-network``
Manages floating and fixed IPs, DHCP, bridging and VLANs. Loads a Service
object which exposes the public methods on one of the subclasses of
NetworkManager. Different networking strategies are available by changing the
``network_manager`` configuration option to ``FlatManager``,
``FlatDHCPManager``, or ``VLANManager`` (defaults to ``VLANManager`` if
nothing is specified).
.. deprecated:: 14.0.0
``nova-network`` was deprecated in the OpenStack Newton release.
``nova-scheduler``
Dispatches requests for new virtual machines to the correct node.
``nova-novncproxy``
Provides a VNC proxy for browsers, allowing VNC consoles to access virtual
machines.
.. note::
Some services have drivers that change how the service implements its core
functionality. For example, the ``nova-compute`` service supports drivers
that let you choose which hypervisor type it can use. ``nova-network`` and
``nova-scheduler`` also have drivers.

View File

@ -74,3 +74,5 @@
/nova/latest/vendordata.html 301 /nova/latest/user/metadata.html
/nova/latest/vmstates.html 301 /nova/latest/reference/vm-states.html
/nova/latest/wsgi.html 301 /nova/latest/user/wsgi.html
/nova/latest/admin/adv-config.html 301 /nova/latest/admin/index.html
/nova/latest/admin/system-admin.html 301 /nova/latest/admin/index.html