openstack/devstack
Code Issues Proposed changes

Merge "Cleanup ReST format issues"

Browse Source
This commit is contained in:
Jenkins 2015-11-16 04:48:05 +00:00 committed by Gerrit Code Review
commit d36c1f3187
4 changed files with 33 additions and 32 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

33
doc/source/configuration.rst
View File

@ -202,8 +202,8 @@ process to a file in ``LOGDIR``.
LOGDIR=$DEST/logs
*Note the use of ``DEST`` to locate the main install directory; this
is why we suggest setting it in ``local.conf``.*
Note the use of ``DEST`` to locate the main install directory; this
is why we suggest setting it in ``local.conf``.
Enabling Syslog
~~~~~~~~~~~~~~~
@ -239,15 +239,15 @@ Database Backend
Multiple database backends are available. The available databases are defined
in the lib/databases directory.
`mysql` is the default database, choose a different one by putting the
following in the `localrc` section:
``mysql`` is the default database, choose a different one by putting the
following in the ``localrc`` section:
::
disable_service mysql
enable_service postgresql
`mysql` is the default database.
``mysql`` is the default database.
RPC Backend
-----------
@ -260,6 +260,7 @@ RabbitMQ is handled via the usual service functions and
Example disabling RabbitMQ in ``local.conf``:
::
disable_service rabbit
@ -511,7 +512,7 @@ VM. When running with only one replica the account, container and
object services will run directly in screen. The others services like
replicator, updaters or auditor runs in background.
If you would like to enable Swift you can add this to your `localrc`
If you would like to enable Swift you can add this to your ``localrc``
section:
::
@ -519,7 +520,7 @@ section:
enable_service s-proxy s-object s-container s-account
If you want a minimal Swift install with only Swift and Keystone you
can have this instead in your `localrc` section:
can have this instead in your ``localrc`` section:
::
@ -528,24 +529,24 @@ can have this instead in your `localrc` section:
If you only want to do some testing of a real normal swift cluster
with multiple replicas you can do so by customizing the variable
`SWIFT_REPLICAS` in your `localrc` section (usually to 3).
``SWIFT_REPLICAS`` in your ``localrc`` section (usually to 3).
Swift S3
++++++++
If you are enabling `swift3` in `ENABLED_SERVICES` DevStack will
If you are enabling ``swift3`` in ``ENABLED_SERVICES`` DevStack will
install the swift3 middleware emulation. Swift will be configured to
act as a S3 endpoint for Keystone so effectively replacing the
`nova-objectstore`.
``nova-objectstore``.
Only Swift proxy server is launched in the screen session all other
services are started in background and managed by `swift-init` tool.
services are started in background and managed by ``swift-init`` tool.
Heat
~~~~
Heat is disabled by default (see `stackrc` file). To enable it
explicitly you'll need the following settings in your `localrc`
Heat is disabled by default (see ``stackrc`` file). To enable it
explicitly you'll need the following settings in your ``localrc``
section
::
@ -554,7 +555,7 @@ section
Heat can also run in standalone mode, and be configured to orchestrate
on an external OpenStack cloud. To launch only Heat in standalone mode
you'll need the following settings in your `localrc` section
you'll need the following settings in your ``localrc`` section
::
@ -590,14 +591,14 @@ Xenserver
~~~~~~~~~
If you would like to use Xenserver as the hypervisor, please refer to
the instructions in `./tools/xen/README.md`.
the instructions in ``./tools/xen/README.md``.
Cells
~~~~~
`Cells <http://wiki.openstack.org/blueprint-nova-compute-cells>`__ is
an alternative scaling option. To setup a cells environment add the
following to your `localrc` section:
following to your ``localrc`` section:
::

2
doc/source/guides/devstack-with-lbaas-v2.rst
View File

@ -17,7 +17,7 @@ Install devstack
cd devstack
Edit your `local.conf` to look like
Edit your ``local.conf`` to look like
::

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

@ -50,7 +50,7 @@ the host:
parm: nested:bool
Start your VM, now it should have KVM capabilities -- you can verify
that by ensuring `/dev/kvm` character device is present.
that by ensuring ``/dev/kvm`` character device is present.
Configure Nested KVM for AMD-based Machines
@ -97,7 +97,7 @@ To make the above value persistent across reboots, add an entry in
Expose Virtualization Extensions to DevStack VM
-----------------------------------------------
Edit the VM's libvirt XML configuration via `virsh` utility:
Edit the VM's libvirt XML configuration via ``virsh`` utility:
::
@ -115,10 +115,10 @@ Ensure DevStack VM is Using KVM
-------------------------------
Before invoking ``stack.sh`` in the VM, ensure that KVM is enabled. This
can be verified by checking for the presence of the file `/dev/kvm` in
can be verified by checking for the presence of the file ``/dev/kvm`` in
your VM. If it is present, DevStack will default to using the config
attribute `virt_type = kvm` in `/etc/nova.conf`; otherwise, it'll fall
back to `virt_type=qemu`, i.e. plain QEMU emulation.
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
@ -131,7 +131,7 @@ DevStack's ``local.conf``:
Once DevStack is configured successfully, verify if the Nova instances
are using KVM by noticing the QEMU CLI invoked by Nova is using the
parameter `accel=kvm`, e.g.:
parameter ``accel=kvm``, e.g.:
::

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

@ -340,8 +340,8 @@ nova, neutron)
**Compute Nodes**
In this example, the nodes that will host guest instances will run
the `neutron-openvswitch-agent` for network connectivity, as well as
the compute service `nova-compute`.
the ``neutron-openvswitch-agent`` for network connectivity, as well as
the compute service ``nova-compute``.
DevStack Configuration
----------------------
@ -426,16 +426,16 @@ compute node 1.
Q_L3_ENABLED=False
Compute node 2's configuration will be exactly the same, except
`HOST_IP` will be `10.0.0.4`
``HOST_IP`` will be ``10.0.0.4``
When DevStack is configured to use provider networking (via
`Q_USE_PROVIDER_NETWORKING` is True and `Q_L3_ENABLED` is False) -
``Q_USE_PROVIDER_NETWORKING`` is True and ``Q_L3_ENABLED`` is False) -
DevStack will automatically add the network interface defined in
`PUBLIC_INTERFACE` to the `OVS_PHYSICAL_BRIDGE`
``PUBLIC_INTERFACE`` to the ``OVS_PHYSICAL_BRIDGE``
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
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.
Miscellaneous Tips
@ -477,7 +477,7 @@ Configuring Extension Drivers for the ML2 Plugin
------------------------------------------------
Extension drivers for the ML2 plugin are set with the variable
`Q_ML2_PLUGIN_EXT_DRIVERS`, and includes the 'port_security' extension
``Q_ML2_PLUGIN_EXT_DRIVERS``, and includes the 'port_security' extension
by default. If you want to remove all the extension drivers (even
'port_security'), set `Q_ML2_PLUGIN_EXT_DRIVERS` to blank.
'port_security'), set ``Q_ML2_PLUGIN_EXT_DRIVERS`` to blank.