openstack/devstack
Code Issues Proposed changes

Merge "made several changes to guides to comply to doc conventions"

Browse Source
This commit is contained in:
Jenkins 2015-04-23 04:04:58 +00:00 committed by Gerrit Code Review
commit cd7655cbfc
5 changed files with 31 additions and 31 deletions
Show Stats 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 Configure Nested KVM for AMD-based Machines
-------------------------------------------- -------------------------------------------
Procedure to enable nested KVM virtualization on 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. back to `virt_type=qemu`, i.e. plain QEMU emulation.
Optionally, to explicitly set the type of virtualization, to KVM, by the 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``: DevStack's ``local.conf``:
:: ::

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

@ -262,17 +262,17 @@ for scripting:
Swift Swift
----- -----
Swift requires a significant amount of resources and is disabled by Swift, OpenStack Object Storage, requires a significant amount of resources
default in DevStack. The support in DevStack is geared toward a minimal and is disabled by default in DevStack. The support in DevStack is geared
installation but can be used for testing. To implement a true multi-node toward a minimal installation but can be used for testing. To implement a
test of Swift required more than DevStack provides. Enabling it is as true multi-node test of swift, additional steps will be required. Enabling it is as
simple as enabling the ``swift`` service in ``local.conf``: simple as enabling the ``swift`` service in ``local.conf``:
:: ::
enable_service s-proxy s-object s-container s-account 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 ``/opt/stack/data/swift``). The size of the data 'partition' created
(really a loop-mounted file) is set by ``SWIFT_LOOPBACK_DISK_SIZE``. The (really a loop-mounted file) is set by ``SWIFT_LOOPBACK_DISK_SIZE``. The
Swift config files are located in ``SWIFT_CONF_DIR`` (default 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 set in ``localrc`` it may be necessary to remove the corresponding
directory from ``/opt/stack`` to force git to re-clone the repository. directory from ``/opt/stack`` to force git to re-clone the repository.
For example, to pull Nova from a proposed release candidate in the For example, to pull nova, OpenStack Compute, from a proposed release candidate
primary Nova repository: in the primary nova repository:
:: ::
NOVA_BRANCH=rc-proposed 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. plugin and the Open vSwitch mechanism driver.
Network Interface Configuration 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. in the host operating system.
The first interface, eth0 is used for the OpenStack management (API, The first interface, eth0 is used for the OpenStack management (API,
@ -62,7 +62,7 @@ connectivity.
Disabling Next Generation Firewall Tools 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, 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 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 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 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 configuring `nova-network` - many of the same configuration variables
(like `FIXED_RANGE` and `FLOATING_RANGE`) used by `nova-network` are (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 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 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 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 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. Nova can attach to the network managed by the external router.
For example, in some lab environments, a hardware router has been For example, in some lab environments, a hardware router has been
pre-configured by another party, and an OpenStack developer 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 given a VLAN tag and IP address range, so that instances created via
DevStack will use the external router for L3 connectivity, as opposed DevStack will use the external router for L3 connectivity, as opposed
to the Neutron L3 service. to the neutron L3 service.
Service Configuration Service Configuration
@ -152,8 +152,8 @@ Service Configuration
**Control Node** **Control Node**
In this example, the control node will run the majority of the In this example, the control node will run the majority of the
OpenStack API and management services (Keystone, Glance, OpenStack API and management services (keystone, glance,
Nova, Neutron, etc..) nova, neutron)
**Compute Nodes** **Compute Nodes**
@ -226,4 +226,4 @@ DevStack will automatically add the network interface defined in
For example, with the above configuration, a bridge is For example, with the above configuration, a bridge is
created, named `br-ex` which is managed by Open vSwitch, and the created, named `br-ex` which is managed by Open vSwitch, and the
second interface on the compute node, `eth1` is attached to 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 This is a rough guide to various configuration parameters for nova
running with devstack. running with DevStack.
nova-serialproxy 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>`_ <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 to allow read/write access to the serial console of an instance via
`nova-serialproxy `nova-serialproxy
@ -60,7 +60,7 @@ The service can be enabled by adding ``n-sproxy`` to
#proxyclient_address=127.0.0.1 #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 These config options are defined in `nova.console.serial
<https://github.com/openstack/nova/blob/master/nova/console/serial.py#L33-L52>`_ <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 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 launched in the cloud will be slow as they are running in QEMU
(emulation), but their primary use is testing OpenStack development and (emulation), but their primary use is testing OpenStack development and
operation. Speed not required. operation.
Prerequisites Cloud & Image Prerequisites Cloud & Image
=========================== ===========================
@ -15,7 +15,7 @@ Virtual Machine
--------------- ---------------
DevStack should run in any virtual machine running a supported Linux 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 OpenStack Deployment & cloud-init
--------------------------------- ---------------------------------
@ -88,7 +88,7 @@ Using OpenStack
--------------- ---------------
At this point you should be able to access the dashboard. Launch VMs and 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. your network.
One interesting use case is for developers working on a VM on their One interesting use case is for developers working on a VM on their