diff --git a/doc/admin-guide-cloud/ch_compute.xml b/doc/admin-guide-cloud/ch_compute.xml index cc3b5346d9..c71309dfe2 100644 --- a/doc/admin-guide-cloud/ch_compute.xml +++ b/doc/admin-guide-cloud/ch_compute.xml @@ -549,7 +549,7 @@ End User Guide, and isn't required here. Comments welcome. LKB xlink:href="http://docs.openstack.org/api/openstack-compute/2/content/" >OpenStack Compute API v2 and Extensions Reference documentation refers to - instances as servers. + instances as servers. The nova cli can be made to show the API calls it is making by passing it the ––debug parameter:--> @@ -1359,7 +1359,8 @@ echo 'Extra user data here' Every virtual instance is automatically assigned a private IP address. You can optionally assign public IP addresses to instances. The term - floating IP refers to + floating + IP refers to an IP address, typically public, that you can dynamically add to a running virtual instance. OpenStack Compute uses Network Address Translation diff --git a/doc/admin-guide-cloud/ch_networking.xml b/doc/admin-guide-cloud/ch_networking.xml index efb5efc2c9..833b58bfe5 100644 --- a/doc/admin-guide-cloud/ch_networking.xml +++ b/doc/admin-guide-cloud/ch_networking.xml @@ -226,9 +226,9 @@ options to decide on the right networking technology for the deployment. In the Havana release, OpenStack Networking provides - the Modular Layer 2 - (ML2) plug-in that can concurrently use - multiple layer 2 networking technologies that are + the + Modular Layer 2 (ML2) plug-in that can concurrently + use multiple layer 2 networking technologies that are found in real-world data centers. It currently works with the existing Open vSwitch, Linux Bridge, and Hyper-v L2 agents. The ML2 framework simplifies the diff --git a/doc/common/ch_using_openstack_overview.xml b/doc/common/ch_using_openstack_overview.xml index 5f4fc0b72e..6f0a38cd68 100644 --- a/doc/common/ch_using_openstack_overview.xml +++ b/doc/common/ch_using_openstack_overview.xml @@ -16,7 +16,7 @@ administrators. As an OpenStack cloud administrative user, you can manage tenants, known as - projects, users, services, images, + projects, users, services, images, flavors, and quotas. The examples in this guide show you how to complete these tasks with either: diff --git a/doc/common/section_cli_nova_userdata.xml b/doc/common/section_cli_nova_userdata.xml index e8573833ea..29e2895b9e 100644 --- a/doc/common/section_cli_nova_userdata.xml +++ b/doc/common/section_cli_nova_userdata.xml @@ -5,7 +5,8 @@ xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="inserting_userdata"> Provide user data to instances - User data is a special key in the + User data is a + special key in the metadata service that holds a file that cloud-aware applications in the guest instance can access. For example the Trusted compute pools Trusted compute pools enable administrators to designate a - group of compute hosts as trusted. These hosts use hardware-based + group of compute hosts as trusted. These hosts use hardware-based security features, such as the Intel Trusted Execution Technology (TXT), to provide an additional level of security. Combined with an external stand-alone web-based remote @@ -144,7 +144,7 @@ auth_blob=i-am-openstack
Specify trusted flavors You must configure one or more flavors as - trusted. Users can request + trusted. Users can request trusted nodes by specifying a trusted flavor when they boot an instance. Use the nova flavor-key set command diff --git a/doc/config-reference/compute/section_compute-configure-migrations.xml b/doc/config-reference/compute/section_compute-configure-migrations.xml index b20a214ae8..8ed7f1b843 100644 --- a/doc/config-reference/compute/section_compute-configure-migrations.xml +++ b/doc/config-reference/compute/section_compute-configure-migrations.xml @@ -110,7 +110,8 @@ HostC. - HostA is the Cloud + HostA is the + Cloud Controller, and should run these services: nova-api, nova-scheduler, @@ -120,8 +121,8 @@ HostB and HostC - are the compute nodes that run - compute nodes + that run nova-compute. diff --git a/doc/config-reference/compute/section_hypervisor_vmware.xml b/doc/config-reference/compute/section_hypervisor_vmware.xml index e898999dbe..6e747c7b4d 100644 --- a/doc/config-reference/compute/section_hypervisor_vmware.xml +++ b/doc/config-reference/compute/section_hypervisor_vmware.xml @@ -110,7 +110,7 @@ DRS. For any cluster that contains multiple ESX hosts, enable DRS and enable - fully automated placement. + fully automated placement. Shared storage. Only diff --git a/doc/install-guide/section_cinder-controller.xml b/doc/install-guide/section_cinder-controller.xml index 2e30496290..4c53b7335a 100644 --- a/doc/install-guide/section_cinder-controller.xml +++ b/doc/install-guide/section_cinder-controller.xml @@ -5,7 +5,8 @@ Configure a Block Storage Service controller This section describes how to configure OpenStack Block Storage - services on the Controller node and assumes that a + services on the Controller node + and assumes that a second node provides storage through the cinder-volume service. For instructions on how to configure the second node, see nova-common, and heat-common packages. In debconf, the - higher the priority for a screen, the + higher the priority for a screen, the greater the chance that the user sees that screen. If a debconf screen has medium priority and you configure the diff --git a/doc/install-guide/section_debconf-preseeding.xml b/doc/install-guide/section_debconf-preseeding.xml index 114424596f..9bbda5050c 100644 --- a/doc/install-guide/section_debconf-preseeding.xml +++ b/doc/install-guide/section_debconf-preseeding.xml @@ -4,7 +4,7 @@ xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"> Pre-seed debconf prompts - You can pre-seed all You can pre-seed all debconf prompts. To pre-seed means to store responses in the debconf database so that debconf does not prompt the user for diff --git a/doc/install-guide/section_neutron-install.xml b/doc/install-guide/section_neutron-install.xml index a2c2184188..8831013577 100644 --- a/doc/install-guide/section_neutron-install.xml +++ b/doc/install-guide/section_neutron-install.xml @@ -694,8 +694,9 @@ use_namespaces = True Configure a firewall plug-in. If you do not wish to - enforce firewall rules, called security - groups by OpenStack, you can use + enforce firewall rules, called security groups + by OpenStack, you can use neutron.agent.firewall.NoopFirewall. Otherwise, you can choose one of the Networking firewall plug-ins. The most common choice is the Hybrid diff --git a/doc/install-guide/section_neutron-provider-router-with-private_networks.xml b/doc/install-guide/section_neutron-provider-router-with-private_networks.xml index 4d6790e67e..e55cc6be3b 100644 --- a/doc/install-guide/section_neutron-provider-router-with-private_networks.xml +++ b/doc/install-guide/section_neutron-provider-router-with-private_networks.xml @@ -625,7 +625,8 @@ export OS_SERVICE_TOKEN=password that tenant. The router object in the API is created and owned by the cloud administrator. This model supports assigning public addresses to VMs by - using floating IPs; the router maps + using floating IPs; + the router maps public addresses from the external network to fixed IPs on private networks. Hosts without floating IPs can still create outbound connections to the external network diff --git a/doc/user-guide-admin/section_dashboard_admin_manage_projects_security.xml b/doc/user-guide-admin/section_dashboard_admin_manage_projects_security.xml index a1f2b2aa65..0c9570f8a2 100644 --- a/doc/user-guide-admin/section_dashboard_admin_manage_projects_security.xml +++ b/doc/user-guide-admin/section_dashboard_admin_manage_projects_security.xml @@ -10,7 +10,7 @@ to the instance. Group rules are project specific; project members can edit the default rules for their group and add new rule sets. - All projects have a default security + All projects have a default security group that is applied to any instance that has no other defined security group. Unless you change the default, this security group denies all incoming traffic and allows only