@@ -54,7 +54,7 @@ that by ensuring `/dev/kvm` character device is present.

 Configure Nested KVM for AMD-based Machines

+-------------------------------------------

 Procedure to enable nested KVM virtualization on AMD-based machines.

@@ -121,7 +121,7 @@ attribute `virt_type = kvm` in `/etc/nova.conf`; otherwise, it'll fall

 back to `virt_type=qemu`, i.e. plain QEMU emulation.

 Optionally, to explicitly set the type of virtualization, to KVM, by the

-libvirt driver in Nova, the below config attribute can be used in

+libvirt driver in nova, the below config attribute can be used in

 DevStack's ``local.conf``:

 ::

@@ -262,17 +262,17 @@ for scripting:

 Swift

 -----

-Swift requires a significant amount of resources and is disabled by

-default in DevStack. The support in DevStack is geared toward a minimal

-installation but can be used for testing. To implement a true multi-node

-test of Swift required more than DevStack provides. Enabling it is as

+Swift, OpenStack Object Storage, requires a significant amount of resources

+and is disabled by default in DevStack. The support in DevStack is geared 

+toward a minimal installation but can be used for testing. To implement a

+true multi-node test of swift, additional steps will be required. Enabling it is as

 simple as enabling the ``swift`` service in ``local.conf``:

 ::

     enable_service s-proxy s-object s-container s-account

-Swift will put its data files in ``SWIFT_DATA_DIR`` (default

+Swift, OpenStack Object Storage, will put its data files in ``SWIFT_DATA_DIR`` (default

 ``/opt/stack/data/swift``). The size of the data 'partition' created

 (really a loop-mounted file) is set by ``SWIFT_LOOPBACK_DISK_SIZE``. The

 Swift config files are located in ``SWIFT_CONF_DIR`` (default

@@ -334,14 +334,14 @@ After making changes to the repository or branch, if ``RECLONE`` is not

 set in ``localrc`` it may be necessary to remove the corresponding

 directory from ``/opt/stack`` to force git to re-clone the repository.

-For example, to pull Nova from a proposed release candidate in the

-primary Nova repository:

+For example, to pull nova, OpenStack Compute, from a proposed release candidate

+in the primary nova repository:

 ::

     NOVA_BRANCH=rc-proposed

-To pull Glance from an experimental fork:

+To pull glance, OpenStack Image service, from an experimental fork:

 ::

@@ -1,14 +1,14 @@

 ======================================

-Using DevStack with Neutron Networking

+Using DevStack with neutron Networking

 ======================================

-This guide will walk you through using OpenStack Neutron with the ML2

+This guide will walk you through using OpenStack neutron with the ML2

 plugin and the Open vSwitch mechanism driver.

 Network Interface Configuration

 ===============================

-To use Neutron, it is suggested that two network interfaces be present

+To use neutron, it is suggested that two network interfaces be present

 in the host operating system.

 The first interface, eth0 is used for the OpenStack management (API,

@@ -62,7 +62,7 @@ connectivity.

 Disabling Next Generation Firewall Tools

 ========================================

-Devstack does not properly operate with modern firewall tools.  Specifically

+DevStack does not properly operate with modern firewall tools.  Specifically

 it will appear as if the guest VM can access the external network via ICMP,

 but UDP and TCP packets will not be delivered to the guest VM.  The root cause

 of the issue is that both ufw (Uncomplicated Firewall) and firewalld (Fedora's

@@ -96,13 +96,13 @@ disable ufw if it was enabled, do the following:

 Neutron Networking with Open vSwitch

 ====================================

-Configuring Neutron networking in DevStack is very similar to

+Configuring neutron, OpenStack Networking in DevStack is very similar to

 configuring `nova-network` - many of the same configuration variables

 (like `FIXED_RANGE` and `FLOATING_RANGE`) used by `nova-network` are

-used by Neutron, which is intentional.

+used by neutron, which is intentional.

 The only difference is the disabling of `nova-network` in your

-local.conf, and the enabling of the Neutron components.

+local.conf, and the enabling of the neutron components.

 Configuration

@@ -134,16 +134,16 @@ in a real setup FLOATING_RANGE would be a public IP address range.

 Neutron Networking with Open vSwitch and Provider Networks

 ==========================================================

-In some instances, it is desirable to use Neutron's provider

+In some instances, it is desirable to use neutron's provider

 networking extension, so that networks that are configured on an

-external router can be utilized by Neutron, and instances created via

+external router can be utilized by neutron, and instances created via

 Nova can attach to the network managed by the external router.

 For example, in some lab environments, a hardware router has been

 pre-configured by another party, and an OpenStack developer has been

 given a VLAN tag and IP address range, so that instances created via

 DevStack will use the external router for L3 connectivity, as opposed

-to the Neutron L3 service.

+to the neutron L3 service.

 Service Configuration

@@ -152,8 +152,8 @@ Service Configuration

 **Control Node**

 In this example, the control node will run the majority of the

-OpenStack API and management services (Keystone, Glance,

-Nova, Neutron, etc..)

+OpenStack API and management services (keystone, glance,

+nova, neutron)

 **Compute Nodes**

@@ -226,4 +226,4 @@ DevStack will automatically add the network interface defined in

 For example, with the above  configuration, a bridge is

 created, named `br-ex` which is managed by Open vSwitch, and the

 second interface on the compute node, `eth1` is attached to the

-bridge, to forward traffic sent by guest vms.

+bridge, to forward traffic sent by guest VMs.

@@ -1,15 +1,15 @@

 =================

-Nova and devstack

+Nova and DevStack

 =================

 This is a rough guide to various configuration parameters for nova

-running with devstack.

+running with DevStack.

 nova-serialproxy

 ================

-In Juno nova implemented a `spec

+In Juno, nova implemented a `spec

 <http://specs.openstack.org/openstack/nova-specs/specs/juno/implemented/serial-ports.html>`_

 to allow read/write access to the serial console of an instance via

 `nova-serialproxy

@@ -60,7 +60,7 @@ The service can be enabled by adding ``n-sproxy`` to

     #proxyclient_address=127.0.0.1

-Enabling the service is enough to be functional for a single machine devstack.

+Enabling the service is enough to be functional for a single machine DevStack.

 These config options are defined in `nova.console.serial

 <https://github.com/openstack/nova/blob/master/nova/console/serial.py#L33-L52>`_

@@ -3,10 +3,10 @@ All-In-One Single VM

 ====================

 Use the cloud to build the cloud! Use your cloud to launch new versions

-of OpenStack in about 5 minutes. When you break it, start over! The VMs

+of OpenStack in about 5 minutes. If you break it, start over! The VMs

 launched in the cloud will be slow as they are running in QEMU

 (emulation), but their primary use is testing OpenStack development and

-operation. Speed not required.

+operation.

 Prerequisites Cloud & Image

 ===========================

@@ -15,7 +15,7 @@ Virtual Machine

 ---------------

 DevStack should run in any virtual machine running a supported Linux

-release. It will perform best with 4Gb or more of RAM.

+release. It will perform best with 4GB or more of RAM.

 OpenStack Deployment & cloud-init

 ---------------------------------

@@ -88,7 +88,7 @@ Using OpenStack

 ---------------

 At this point you should be able to access the dashboard. Launch VMs and

-if you give them floating IPs access those VMs from other machines on

+if you give them floating IPs, access those VMs from other machines on

 your network.

 One interesting use case is for developers working on a VM on their