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:
parent
c5d094ad3d
commit
da207cc2be
|
@ -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
|
||||
|
|
|
@ -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
|
|
@ -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
|
||||
|
|
|
@ -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.
|
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue