openstack/devstack
Code Issues Proposed changes

made several changes to guides to comply to doc conventions

Browse Source 
“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
This commit is contained in:
Shilla Saebi
2015-04-21 15:02:13 -04:00
parent 7c17f2684e
commit 2ed09d88fb
5 changed files with 31 additions and 31 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
doc/source/guides/devstack-with-nested-kvm.rst
View File

@@ -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``:
::

16
doc/source/guides/multinode-lab.rst
View File

@@ -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:
::

26
doc/source/guides/neutron.rst
View File

@@ -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.

8
doc/source/guides/nova.rst
View File

@@ -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>`_

8
doc/source/guides/single-vm.rst
View File

@@ -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