From 2ed09d88fb2847fe8ec813bf518dd945d8d813fa Mon Sep 17 00:00:00 2001 From: Shilla Saebi Date: Tue, 21 Apr 2015 15:02:13 -0400 Subject: [PATCH] made several changes to guides to comply to doc conventions MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit “Speed not required” is not a sentence Gb should be GB added a , after floating IPs fixed sentence around “To implement a true multi-node test of Swift since it did not make sense removed extra underline line after Machines removed capitalization of service names to comply with docs conventions https://wiki.openstack.org/wiki/Documentation/Conventions changed to DevStack for consistency throughout Change-Id: I531bf6b2bad62fbf9d1417b2b1ce06de3715e0f0 --- .../guides/devstack-with-nested-kvm.rst | 4 +-- doc/source/guides/multinode-lab.rst | 16 ++++++------ doc/source/guides/neutron.rst | 26 +++++++++---------- doc/source/guides/nova.rst | 8 +++--- doc/source/guides/single-vm.rst | 8 +++--- 5 files changed, 31 insertions(+), 31 deletions(-) diff --git a/doc/source/guides/devstack-with-nested-kvm.rst b/doc/source/guides/devstack-with-nested-kvm.rst index 610300be52..b35492ea17 100644 --- a/doc/source/guides/devstack-with-nested-kvm.rst +++ b/doc/source/guides/devstack-with-nested-kvm.rst @@ -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``: :: diff --git a/doc/source/guides/multinode-lab.rst b/doc/source/guides/multinode-lab.rst index d963243fa8..b2617c9f17 100644 --- a/doc/source/guides/multinode-lab.rst +++ b/doc/source/guides/multinode-lab.rst @@ -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: :: diff --git a/doc/source/guides/neutron.rst b/doc/source/guides/neutron.rst index 95cde9699a..3030c7b5f2 100644 --- a/doc/source/guides/neutron.rst +++ b/doc/source/guides/neutron.rst @@ -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. diff --git a/doc/source/guides/nova.rst b/doc/source/guides/nova.rst index 0d98f4abad..a91e0d194c 100644 --- a/doc/source/guides/nova.rst +++ b/doc/source/guides/nova.rst @@ -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 `_ 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 `_ diff --git a/doc/source/guides/single-vm.rst b/doc/source/guides/single-vm.rst index ab46d91b83..c2ce1a34a0 100644 --- a/doc/source/guides/single-vm.rst +++ b/doc/source/guides/single-vm.rst @@ -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