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 `__ 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 ee29087267..996c7d1f59 100644 --- a/doc/source/guides/neutron.rst +++ b/doc/source/guides/neutron.rst @@ -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.