Merge "made several changes to guides to comply to doc conventions"
This commit is contained in:
Jenkins
Gerrit Code Review
commit
cd7655cbfc
@ -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
|
||||
|
||||
Loading…
Reference in New Issue
Block a user