diff --git a/doc/source/configuration.rst b/doc/source/configuration.rst
index d70d3dae17..e9921f049c 100644
--- a/doc/source/configuration.rst
+++ b/doc/source/configuration.rst
@@ -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:
::
diff --git a/doc/source/guides/devstack-with-lbaas-v2.rst b/doc/source/guides/devstack-with-lbaas-v2.rst
index f67978310d..4e5f874787 100644
--- a/doc/source/guides/devstack-with-lbaas-v2.rst
+++ b/doc/source/guides/devstack-with-lbaas-v2.rst
@@ -17,7 +17,7 @@ Install devstack
cd devstack
-Edit your `local.conf` to look like
+Edit your ``local.conf`` to look like
::
diff --git a/doc/source/guides/devstack-with-nested-kvm.rst b/doc/source/guides/devstack-with-nested-kvm.rst
index c652bacced..85a5656198 100644
--- a/doc/source/guides/devstack-with-nested-kvm.rst
+++ b/doc/source/guides/devstack-with-nested-kvm.rst
@@ -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.:
::
diff --git a/doc/source/guides/neutron.rst b/doc/source/guides/neutron.rst
index 5891f68033..5e231315f7 100644
--- a/doc/source/guides/neutron.rst
+++ b/doc/source/guides/neutron.rst
@@ -170,8 +170,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
----------------------
@@ -256,16 +256,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
@@ -307,7 +307,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.