diff --git a/doc/admin-guide-cloud/blockstorage/section_backup-block-storage-disks.xml b/doc/admin-guide-cloud/blockstorage/section_backup-block-storage-disks.xml index d5089bd249..51b1aa6069 100644 --- a/doc/admin-guide-cloud/blockstorage/section_backup-block-storage-disks.xml +++ b/doc/admin-guide-cloud/blockstorage/section_backup-block-storage-disks.xml @@ -222,7 +222,7 @@ Block device 251:14 Unmount the volume: - unmount /mnt + umount /mnt Delete the partition table: diff --git a/doc/admin-guide-cloud/blockstorage/section_ts_cinder_config.xml b/doc/admin-guide-cloud/blockstorage/section_ts_cinder_config.xml index c3919510fe..c4a102578c 100644 --- a/doc/admin-guide-cloud/blockstorage/section_ts_cinder_config.xml +++ b/doc/admin-guide-cloud/blockstorage/section_ts_cinder_config.xml @@ -111,7 +111,7 @@ Issues with state_path and volumes_dir settings. The OpenStack Block Storage uses tgtd - as the default iscsi helper and implements persistent targets. + as the default iSCSI helper and implements persistent targets. This means that in the case of a tgt restart or even a node reboot your existing volumes on that node will be restored automatically with their original IQN. diff --git a/doc/admin-guide-cloud/ch_compute.xml b/doc/admin-guide-cloud/ch_compute.xml index 387ec4d249..d59c14767e 100644 --- a/doc/admin-guide-cloud/ch_compute.xml +++ b/doc/admin-guide-cloud/ch_compute.xml @@ -62,7 +62,7 @@ controllers, and the object store or image service. The state of the entire system is stored in a database. The cloud controller communicates with the internal object store using HTTP, but it communicates with the scheduler, network controller, and volume - controller using AMQP (advanced message queueing protocol). To avoid blocking a + controller using AMQP (advanced message queuing protocol). To avoid blocking a component while waiting for a response, Compute uses asynchronous calls, with a callback that is triggered when a response is received.
@@ -323,7 +323,7 @@ volume in the Cinder volume system. This gives a more traditional persistent system that accumulates states, which are preserved on the Cinder volume across the - deletion and re-creation of the virutal machine. To get a + deletion and re-creation of the virtual machine. To get a list of available images on your system run: $ nova image-list +--------------------------------------+-------------------------------+--------+--------------------------------------+ diff --git a/doc/admin-guide-cloud/ch_identity_mgmt.xml b/doc/admin-guide-cloud/ch_identity_mgmt.xml index cf183e8857..711c8a4b8e 100644 --- a/doc/admin-guide-cloud/ch_identity_mgmt.xml +++ b/doc/admin-guide-cloud/ch_identity_mgmt.xml @@ -48,7 +48,7 @@ pipeline = stats_monitoring url_normalize token_auth admin_token_auth xml_body j $ curl -X PATCH http://localhost:5000/v2.0/OS-KSCRUD/users/USERID -H "Content-type: application/json" \ -H "X_Auth_Token: AUTHTOKENID" -d '{"user": {"password": "ABCD", "original_password": "DCBA"}}' In addition to changing their password, all current - tokens for the user are deleted (if the back end is KVS or sql). + tokens for the user are deleted (if the back end is KVS or SQL). Only use a KVS back end for tokens when testing.
diff --git a/doc/admin-guide-cloud/compute/section_compute-system-admin.xml b/doc/admin-guide-cloud/compute/section_compute-system-admin.xml index d7ddf91e93..1b810d5a50 100644 --- a/doc/admin-guide-cloud/compute/section_compute-system-admin.xml +++ b/doc/admin-guide-cloud/compute/section_compute-system-admin.xml @@ -18,7 +18,7 @@ nova-api. Receives XML - requests and sends them to the rest of the system. It is a wsgi app that + requests and sends them to the rest of the system. It is a WSGI app that routes and authenticate requests. It supports the EC2 and OpenStack APIs. There is a nova-api.conf file created when you install Compute. diff --git a/doc/admin-guide-cloud/networking/section_networking-adv-config.xml b/doc/admin-guide-cloud/networking/section_networking-adv-config.xml index 713dbbfc4d..64a5fed97b 100644 --- a/doc/admin-guide-cloud/networking/section_networking-adv-config.xml +++ b/doc/admin-guide-cloud/networking/section_networking-adv-config.xml @@ -9,7 +9,7 @@ /etc/neutron.
OpenStack Networking server with plug-in - This web server runs the OpenStack Networking API Web Server. It laods + This web server runs the OpenStack Networking API Web Server. It loads a plug-in and passes the API calls to the plug-in for processing. The neutron-server service receives one or more configuration files as input. For example: diff --git a/doc/admin-guide-cloud/networking/section_networking-multi-dhcp-agents.xml b/doc/admin-guide-cloud/networking/section_networking-multi-dhcp-agents.xml index 58a9d11bb4..e7f2c29b2b 100644 --- a/doc/admin-guide-cloud/networking/section_networking-multi-dhcp-agents.xml +++ b/doc/admin-guide-cloud/networking/section_networking-multi-dhcp-agents.xml @@ -96,7 +96,7 @@ physical_interface_mappings = physnet1:eth0 - HostA and Hostb: L2 agent + HostA and HostB: L2 agent Neutron configuration file /etc/neutron/neutron.conf: diff --git a/doc/admin-guide-cloud/section_object-storage-monitoring.xml b/doc/admin-guide-cloud/section_object-storage-monitoring.xml index 736bf7ce04..217b44f3dc 100644 --- a/doc/admin-guide-cloud/section_object-storage-monitoring.xml +++ b/doc/admin-guide-cloud/section_object-storage-monitoring.xml @@ -290,7 +290,7 @@ def process_container(self, dbfile): with a similar-looking project also hosted on - GitHub), but the released version on PyPi was missing two + GitHub), but the released version on PyPI was missing two desired features the latest version in GitHub had: the ability to configure a metrics prefix in the client object and a convenience method for sending timing data between diff --git a/doc/arch-design/compute_focus/section_architecture_compute_focus.xml b/doc/arch-design/compute_focus/section_architecture_compute_focus.xml index 8793e6ee10..92ca2d4929 100644 --- a/doc/arch-design/compute_focus/section_architecture_compute_focus.xml +++ b/doc/arch-design/compute_focus/section_architecture_compute_focus.xml @@ -518,7 +518,7 @@ The exclusion of certain OpenStack components might also limit or constrain the functionality of other components. If a design opts to include the Orchestration module but exclude the Telemetry module, then - the design will not be able to take advantage of Orchestration's aut + the design will not be able to take advantage of Orchestration's auto scaling functionality (which relies on information from Telemetry). Due to the fact that you can use Orchestration to spin up a large number of instances to perform the compute-intensive processing, including @@ -592,7 +592,7 @@ information. Selection of an appropriate back-end database that will satisfy the availability and fault tolerance requirements of the OpenStack services is required. OpenStack services support connecting - to any database that is supported by the sqlalchemy Python drivers, + to any database that is supported by the SQLAlchemy Python drivers, however most common database deployments make use of MySQL or some variation of it. It is recommended that the database which provides back-end service within a general purpose cloud be made highly diff --git a/doc/arch-design/generalpurpose/section_architecture_general_purpose.xml b/doc/arch-design/generalpurpose/section_architecture_general_purpose.xml index 9fc72df589..447a400b54 100644 --- a/doc/arch-design/generalpurpose/section_architecture_general_purpose.xml +++ b/doc/arch-design/generalpurpose/section_architecture_general_purpose.xml @@ -209,7 +209,7 @@ expandability) to match the requirements of selected scale-out storage solution. For example, if a centralized storage solution is required, such as a centralized storage array from - a storage vendor that has infiniBand or FDDI connections, the + a storage vendor that has InfiniBand or FDDI connections, the server hardware will need to have appropriate network adapters installed to be compatible with the storage array vendor's specifications. diff --git a/doc/arch-design/network_focus/section_architecture_network_focus.xml b/doc/arch-design/network_focus/section_architecture_network_focus.xml index 075569b3a9..063c0bffe1 100644 --- a/doc/arch-design/network_focus/section_architecture_network_focus.xml +++ b/doc/arch-design/network_focus/section_architecture_network_focus.xml @@ -38,7 +38,7 @@ be required to fill in the functional gaps. Hardware load balancers are an example of equipment that may be necessary to distribute workloads or offload certain functions. Note that, - as of the icehouse release, dynamic routing is currently in + as of the Icehouse release, dynamic routing is currently in its infancy within OpenStack and may need to be implemented either by an external device or a specialized service instance within OpenStack. Tunneling is a feature provided by OpenStack Networking, @@ -148,7 +148,7 @@ A design decision that many overlook is a choice of layer 3 protocols. While OpenStack was initially built with only IPv4 support, Networking now supports IPv6 and dual-stacked networks. - Note that, as of the icehouse release, this only includes + Note that, as of the Icehouse release, this only includes stateless address autoconfiguration but the work is in progress to support stateless and stateful dhcpv6 as well as IPv6 floating IPs without NAT. Some workloads become possible @@ -158,7 +158,7 @@ options are available. This will alter the requirements for any address plan as single-stacked and transitional IPv6 deployments can alleviate the need for IPv4 addresses. - As of the icehouse release, OpenStack has limited support + As of the Icehouse release, OpenStack has limited support for dynamic routing, however there are a number of options available by incorporating third party solutions to implement routing within the cloud including network equipment, hardware diff --git a/doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml b/doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml index bcd22749ea..1512ab5b73 100644 --- a/doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml +++ b/doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml @@ -74,7 +74,7 @@ for large scale performance-oriented systems. This example discusses an OpenStack Object Store with a high performance requirement. OpenStack has integration with Hadoop - through the Data processing project (sahara), which is leveraged + through the Data processing project (Sahara), which is leveraged to manage the Hadoop cluster within the cloud. diff --git a/doc/cli-reference/ch_cli_glance_property_keys.xml b/doc/cli-reference/ch_cli_glance_property_keys.xml index 371ee529ba..0ed870c943 100644 --- a/doc/cli-reference/ch_cli_glance_property_keys.xml +++ b/doc/cli-reference/ch_cli_glance_property_keys.xml @@ -310,7 +310,7 @@ libvirt API driver os_command_line The kernel command line to be used by the libvirt driver, instead of the - default. For linux containers (LXC), the value is used as arguments for + default. For Linux Containers (LXC), the value is used as arguments for initialization. This key is valid only for Amazon kernel, ramdisk, or machine images (aki, ari, or ami). diff --git a/doc/cli-reference/ch_cli_neutron-debug_commands.xml b/doc/cli-reference/ch_cli_neutron-debug_commands.xml index fdbe2fe1f5..0ad859f6da 100644 --- a/doc/cli-reference/ch_cli_neutron-debug_commands.xml +++ b/doc/cli-reference/ch_cli_neutron-debug_commands.xml @@ -191,7 +191,7 @@ <ca-certificate> Specify a CA bundle file to use in verifying a TLS - (https) server certificate. Defaults to + (HTTPS) server certificate. Defaults to env[OS_CACERT] @@ -200,7 +200,7 @@ --insecure Explicitly allow neutron-debug to perform "insecure" - SSL (https) requests. The server's certificate will not be + SSL (HTTPS) requests. The server's certificate will not be verified against any certificate authorities. This option should be used with caution.