openstack/openstack-manuals
Code Issues Proposed changes

Use small letters for node names

Browse Source 
Change-Id: Icce849acc702f10038285cbe98342b5c38cd8b5b
This commit is contained in:
KATO Tomoyuki 2017-01-10 11:38:24 +09:00
parent 17a4fe0fe8
commit 9937d82cde
12 changed files with 24 additions and 24 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
doc/admin-guide/source/compute-images-instances.rst
View File

@ -300,10 +300,10 @@ image is transferred over this connection. The Image service streams the
image from the back end to the compute node. image from the back end to the compute node.
It is possible to set up the Object Storage node on a separate network, It is possible to set up the Object Storage node on a separate network,
and still allow image traffic to flow between the Compute and Object and still allow image traffic to flow between the compute and object
Storage nodes. Configure the ``my_block_storage_ip`` option in the storage nodes. Configure the ``my_block_storage_ip`` option in the
storage node configuration file to allow block storage traffic to reach storage node configuration file to allow block storage traffic to reach
the Compute node. the compute node.
Certain back ends support a more direct method, where on request the Certain back ends support a more direct method, where on request the
Image service will return a URL that links directly to the back-end store. Image service will return a URL that links directly to the back-end store.

4
doc/admin-guide/source/compute-system-admin.rst
View File

@ -23,7 +23,7 @@ System administration
compute-node-down.rst compute-node-down.rst
compute-adv-config.rst compute-adv-config.rst
To effectively administer Compute, you must understand how the different To effectively administer compute, you must understand how the different
installed nodes interact with each other. Compute can be installed in installed nodes interact with each other. Compute can be installed in
many different ways using multiple servers, but generally multiple many different ways using multiple servers, but generally multiple
compute nodes control the virtual servers and a cloud controller node compute nodes control the virtual servers and a cloud controller node
@ -51,7 +51,7 @@ deployment. The responsibilities of services and drivers are:
Procedure Call (RPC). Procedure Call (RPC).
``nova-conductor`` ``nova-conductor``
provides database-access support for Compute nodes provides database-access support for compute nodes
(thereby reducing security risks). (thereby reducing security risks).
``nova-consoleauth`` ``nova-consoleauth``

2
doc/admin-guide/source/networking-arch.rst
View File

@ -77,7 +77,7 @@ controller.
The diagrams below depict some VMware NSX deployment examples. The first The diagrams below depict some VMware NSX deployment examples. The first
diagram illustrates the traffic flow between VMs on separate Compute diagram illustrates the traffic flow between VMs on separate Compute
nodes, and the second diagram between two VMs on a single Compute node. nodes, and the second diagram between two VMs on a single compute node.
Note the placement of the VMware NSX plug-in and the neutron-server Note the placement of the VMware NSX plug-in and the neutron-server
service on the network node. The green arrow indicates the management service on the network node. The green arrow indicates the management
relationship between the NSX controller and the network node. relationship between the NSX controller and the network node.

12
doc/admin-guide/source/telemetry-data-collection.rst
View File

@ -200,7 +200,7 @@ Compute agent
------------- -------------
This agent is responsible for collecting resource usage data of VM This agent is responsible for collecting resource usage data of VM
instances on individual Compute nodes within an OpenStack deployment. instances on individual compute nodes within an OpenStack deployment.
This mechanism requires a closer interaction with the hypervisor, This mechanism requires a closer interaction with the hypervisor,
therefore a separate agent type fulfills the collection of the related therefore a separate agent type fulfills the collection of the related
meters, which is placed on the host machines to retrieve this meters, which is placed on the host machines to retrieve this
@ -218,7 +218,7 @@ database connection. The samples are sent via AMQP to the notification agent.
The list of supported hypervisors can be found in The list of supported hypervisors can be found in
:ref:`telemetry-supported-hypervisors`. The Compute agent uses the API of the :ref:`telemetry-supported-hypervisors`. The Compute agent uses the API of the
hypervisor installed on the Compute hosts. Therefore, the supported meters may hypervisor installed on the compute hosts. Therefore, the supported meters may
be different in case of each virtualization back end, as each inspection tool be different in case of each virtualization back end, as each inspection tool
provides a different set of meters. provides a different set of meters.
@ -272,7 +272,7 @@ instances.
Therefore Telemetry uses another method to gather this data by polling Therefore Telemetry uses another method to gather this data by polling
the infrastructure including the APIs of the different OpenStack the infrastructure including the APIs of the different OpenStack
services and other assets, like hypervisors. The latter case requires services and other assets, like hypervisors. The latter case requires
closer interaction with the Compute hosts. To solve this issue, closer interaction with the compute hosts. To solve this issue,
Telemetry uses an agent based architecture to fulfill the requirements Telemetry uses an agent based architecture to fulfill the requirements
against the data collection. against the data collection.
@ -359,15 +359,15 @@ IPMI agent
---------- ----------
This agent is responsible for collecting IPMI sensor data and Intel Node This agent is responsible for collecting IPMI sensor data and Intel Node
Manager data on individual Compute nodes within an OpenStack deployment. Manager data on individual compute nodes within an OpenStack deployment.
This agent requires an IPMI capable node with the ipmitool utility installed, This agent requires an IPMI capable node with the ipmitool utility installed,
which is commonly used for IPMI control on various Linux distributions. which is commonly used for IPMI control on various Linux distributions.
An IPMI agent instance could be installed on each and every Compute node An IPMI agent instance could be installed on each and every compute node
with IPMI support, except when the node is managed by the Bare metal with IPMI support, except when the node is managed by the Bare metal
service and the ``conductor.send_sensor_data`` option is set to ``true`` service and the ``conductor.send_sensor_data`` option is set to ``true``
in the Bare metal service. It is no harm to install this agent on a in the Bare metal service. It is no harm to install this agent on a
Compute node without IPMI or Intel Node Manager support, as the agent compute node without IPMI or Intel Node Manager support, as the agent
checks for the hardware and if none is available, returns empty data. It checks for the hardware and if none is available, returns empty data. It
is suggested that you install the IPMI agent only on an IPMI capable is suggested that you install the IPMI agent only on an IPMI capable
node for performance reasons. node for performance reasons.

2
doc/arch-design-draft/source/use-cases/use-case-general-compute.rst
View File

@ -37,7 +37,7 @@ The solution would consist of the following OpenStack components:
RabbitMQ, configured for high availability on at least three controller RabbitMQ, configured for high availability on at least three controller
nodes. nodes.
* OpenStack Compute nodes running the KVM hypervisor. * OpenStack compute nodes running the KVM hypervisor.
* OpenStack Block Storage for use by compute instances, requiring * OpenStack Block Storage for use by compute instances, requiring
persistent storage (such as databases for dynamic sites). persistent storage (such as databases for dynamic sites).

6
doc/arch-design/source/generalpurpose-prescriptive-example.rst
View File

@ -31,7 +31,7 @@ The solution would consist of the following OpenStack components:
combined with support services such as MariaDB and RabbitMQ, combined with support services such as MariaDB and RabbitMQ,
configured for high availability on at least three controller nodes. configured for high availability on at least three controller nodes.
* OpenStack Compute nodes running the KVM hypervisor. * OpenStack compute nodes running the KVM hypervisor.
* OpenStack Block Storage for use by compute instances, requiring * OpenStack Block Storage for use by compute instances, requiring
persistent storage (such as databases for dynamic sites). persistent storage (such as databases for dynamic sites).
@ -44,10 +44,10 @@ Running up to 140 web instances and the small number of MariaDB
instances requires 292 vCPUs available, as well as 584 GB RAM. On a instances requires 292 vCPUs available, as well as 584 GB RAM. On a
typical 1U server using dual-socket hex-core Intel CPUs with typical 1U server using dual-socket hex-core Intel CPUs with
Hyperthreading, and assuming 2:1 CPU overcommit ratio, this would Hyperthreading, and assuming 2:1 CPU overcommit ratio, this would
require 8 OpenStack Compute nodes. require 8 OpenStack compute nodes.
The web application instances run from local storage on each of the The web application instances run from local storage on each of the
OpenStack Compute nodes. The web application instances are stateless, OpenStack compute nodes. The web application instances are stateless,
meaning that any of the instances can fail and the application will meaning that any of the instances can fail and the application will
continue to function. continue to function.

2
doc/arch-design/source/multi-site-prescriptive-examples.rst
View File

@ -100,7 +100,7 @@ The solution would consist of the following OpenStack components:
nodes in each of the region providing a redundant OpenStack nodes in each of the region providing a redundant OpenStack
Controller plane throughout the globe. Controller plane throughout the globe.
* OpenStack Compute nodes running the KVM hypervisor. * OpenStack compute nodes running the KVM hypervisor.
* OpenStack Object Storage for serving static objects such as images * OpenStack Object Storage for serving static objects such as images
can be used to ensure that all images are standardized across all the can be used to ensure that all images are standardized across all the

2
doc/arch-design/source/specialized-openstack-on-openstack.rst
View File

@ -52,7 +52,7 @@ Possible solutions: hypervisor
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In the case of running TripleO, the underlying OpenStack In the case of running TripleO, the underlying OpenStack
cloud deploys the Compute nodes as bare-metal. You then deploy cloud deploys the compute nodes as bare-metal. You then deploy
OpenStack on these Compute bare-metal servers with the OpenStack on these Compute bare-metal servers with the
appropriate hypervisor, such as KVM. appropriate hypervisor, such as KVM.

6
doc/config-reference/source/block-storage/drivers/emc-vnx-driver.rst
View File

@ -338,7 +338,7 @@ Storage group automatic deletion
For volume attaching, the driver has a storage group on VNX for each compute For volume attaching, the driver has a storage group on VNX for each compute
node hosting the vm instances which are going to consume VNX Block Storage node hosting the vm instances which are going to consume VNX Block Storage
(using compute node's host name as storage group's name). All the volumes (using compute node's host name as storage group's name). All the volumes
attached to the VM instances in a Compute node will be put into the storage attached to the VM instances in a compute node will be put into the storage
group. If ``destroy_empty_storage_group`` is set to ``True``, the driver will group. If ``destroy_empty_storage_group`` is set to ``True``, the driver will
remove the empty storage group after its last volume is detached. For data remove the empty storage group after its last volume is detached. For data
safety, it does not suggest to set ``destroy_empty_storage_group=True`` unless safety, it does not suggest to set ``destroy_empty_storage_group=True`` unless
@ -379,7 +379,7 @@ iSCSI initiators
---------------- ----------------
``iscsi_initiators`` is a dictionary of IP addresses of the iSCSI ``iscsi_initiators`` is a dictionary of IP addresses of the iSCSI
initiator ports on OpenStack Compute and Block Storage nodes which want to initiator ports on OpenStack compute and block storage nodes which want to
connect to VNX via iSCSI. If this option is configured, the driver will connect to VNX via iSCSI. If this option is configured, the driver will
leverage this information to find an accessible iSCSI target portal for the leverage this information to find an accessible iSCSI target portal for the
initiator when attaching volume. Otherwise, the iSCSI target portal will be initiator when attaching volume. Otherwise, the iSCSI target portal will be
@ -781,7 +781,7 @@ Enabling multipath volume access is recommended for robust data access.
The major configuration includes: The major configuration includes:
#. Install ``multipath-tools``, ``sysfsutils`` and ``sg3-utils`` on the #. Install ``multipath-tools``, ``sysfsutils`` and ``sg3-utils`` on the
nodes hosting Nova-Compute and Cinder-Volume services. Check nodes hosting compute and ``cinder-volume`` services. Check
the operating system manual for the system distribution for specific the operating system manual for the system distribution for specific
installation steps. For Red Hat based distributions, they should be installation steps. For Red Hat based distributions, they should be
``device-mapper-multipath``, ``sysfsutils`` and ``sg3_utils``. ``device-mapper-multipath``, ``sysfsutils`` and ``sg3_utils``.

2
doc/ha-guide/source/storage-ha-backend.rst
View File

@ -10,7 +10,7 @@ An OpenStack environment includes multiple data pools for the VMs:
- Ephemeral storage is allocated for an instance and is deleted when the - Ephemeral storage is allocated for an instance and is deleted when the
instance is deleted. The Compute service manages ephemeral storage and instance is deleted. The Compute service manages ephemeral storage and
by default, Compute stores ephemeral drives as files on local disks on the by default, Compute stores ephemeral drives as files on local disks on the
Compute node. As an alternative, you can use Ceph RBD as the storage back compute node. As an alternative, you can use Ceph RBD as the storage back
end for ephemeral storage. end for ephemeral storage.
- Persistent storage exists outside all instances. Two types of persistent - Persistent storage exists outside all instances. Two types of persistent

2
doc/networking-guide/source/config-ovs-dpdk.rst
View File

@ -18,7 +18,7 @@ interfaces can connect guests to this datapath. For more information on DPDK,
refer to the `DPDK <http://dpdk.org/>`__ website. refer to the `DPDK <http://dpdk.org/>`__ website.
OVS with DPDK, or OVS-DPDK, can be used to provide high-performance networking OVS with DPDK, or OVS-DPDK, can be used to provide high-performance networking
between instances on OpenStack Compute nodes. between instances on OpenStack compute nodes.
Prerequisites Prerequisites
------------- -------------

2
doc/ops-guide/source/ops-monitoring.rst
View File

@ -332,7 +332,7 @@ staple.
You can create automated alerts for critical processes by using Nagios You can create automated alerts for critical processes by using Nagios
and NRPE. For example, to ensure that the ``nova-compute`` process is and NRPE. For example, to ensure that the ``nova-compute`` process is
running on Compute nodes, create an alert on your Nagios server: running on the compute nodes, create an alert on your Nagios server:
.. code-block:: ini .. code-block:: ini