* ReST doesn't allow monospace in italic sections.
bash$ grep -R \`\` doc/build/html/ --include "*.html"
* The code-block section "::" needed an empty line before the code,
otherwise it gets shown in the HTML output.
bash$ egrep -R "<dt>::" doc/build/html/ --include "*.html"
* Monospaced font incorrectly marked with a single back tick
bash$ egrep -nR '\w`(\s|[\.,;:])' doc/source/ --include "*.rst"
Change-Id: I66c3f685f33851c3f3f0f859996037fc24930246
... | ... |
@@ -202,8 +202,8 @@ process to a file in ``LOGDIR``. |
202 | 202 |
|
203 | 203 |
LOGDIR=$DEST/logs |
204 | 204 |
|
205 |
-*Note the use of ``DEST`` to locate the main install directory; this |
|
206 |
-is why we suggest setting it in ``local.conf``.* |
|
205 |
+Note the use of ``DEST`` to locate the main install directory; this |
|
206 |
+is why we suggest setting it in ``local.conf``. |
|
207 | 207 |
|
208 | 208 |
Enabling Syslog |
209 | 209 |
~~~~~~~~~~~~~~~ |
... | ... |
@@ -239,15 +239,15 @@ Database Backend |
239 | 239 |
|
240 | 240 |
Multiple database backends are available. The available databases are defined |
241 | 241 |
in the lib/databases directory. |
242 |
-`mysql` is the default database, choose a different one by putting the |
|
243 |
-following in the `localrc` section: |
|
242 |
+``mysql`` is the default database, choose a different one by putting the |
|
243 |
+following in the ``localrc`` section: |
|
244 | 244 |
|
245 | 245 |
:: |
246 | 246 |
|
247 | 247 |
disable_service mysql |
248 | 248 |
enable_service postgresql |
249 | 249 |
|
250 |
-`mysql` is the default database. |
|
250 |
+``mysql`` is the default database. |
|
251 | 251 |
|
252 | 252 |
RPC Backend |
253 | 253 |
----------- |
... | ... |
@@ -260,6 +260,7 @@ RabbitMQ is handled via the usual service functions and |
260 | 260 |
Example disabling RabbitMQ in ``local.conf``: |
261 | 261 |
|
262 | 262 |
:: |
263 |
+ |
|
263 | 264 |
disable_service rabbit |
264 | 265 |
|
265 | 266 |
|
... | ... |
@@ -511,7 +512,7 @@ VM. When running with only one replica the account, container and |
511 | 511 |
object services will run directly in screen. The others services like |
512 | 512 |
replicator, updaters or auditor runs in background. |
513 | 513 |
|
514 |
-If you would like to enable Swift you can add this to your `localrc` |
|
514 |
+If you would like to enable Swift you can add this to your ``localrc`` |
|
515 | 515 |
section: |
516 | 516 |
|
517 | 517 |
:: |
... | ... |
@@ -519,7 +520,7 @@ section: |
519 | 519 |
enable_service s-proxy s-object s-container s-account |
520 | 520 |
|
521 | 521 |
If you want a minimal Swift install with only Swift and Keystone you |
522 |
-can have this instead in your `localrc` section: |
|
522 |
+can have this instead in your ``localrc`` section: |
|
523 | 523 |
|
524 | 524 |
:: |
525 | 525 |
|
... | ... |
@@ -528,24 +529,24 @@ can have this instead in your `localrc` section: |
528 | 528 |
|
529 | 529 |
If you only want to do some testing of a real normal swift cluster |
530 | 530 |
with multiple replicas you can do so by customizing the variable |
531 |
-`SWIFT_REPLICAS` in your `localrc` section (usually to 3). |
|
531 |
+``SWIFT_REPLICAS`` in your ``localrc`` section (usually to 3). |
|
532 | 532 |
|
533 | 533 |
Swift S3 |
534 | 534 |
++++++++ |
535 | 535 |
|
536 |
-If you are enabling `swift3` in `ENABLED_SERVICES` DevStack will |
|
536 |
+If you are enabling ``swift3`` in ``ENABLED_SERVICES`` DevStack will |
|
537 | 537 |
install the swift3 middleware emulation. Swift will be configured to |
538 | 538 |
act as a S3 endpoint for Keystone so effectively replacing the |
539 |
-`nova-objectstore`. |
|
539 |
+``nova-objectstore``. |
|
540 | 540 |
|
541 | 541 |
Only Swift proxy server is launched in the screen session all other |
542 |
-services are started in background and managed by `swift-init` tool. |
|
542 |
+services are started in background and managed by ``swift-init`` tool. |
|
543 | 543 |
|
544 | 544 |
Heat |
545 | 545 |
~~~~ |
546 | 546 |
|
547 |
-Heat is disabled by default (see `stackrc` file). To enable it |
|
548 |
-explicitly you'll need the following settings in your `localrc` |
|
547 |
+Heat is disabled by default (see ``stackrc`` file). To enable it |
|
548 |
+explicitly you'll need the following settings in your ``localrc`` |
|
549 | 549 |
section |
550 | 550 |
|
551 | 551 |
:: |
... | ... |
@@ -554,7 +555,7 @@ section |
554 | 554 |
|
555 | 555 |
Heat can also run in standalone mode, and be configured to orchestrate |
556 | 556 |
on an external OpenStack cloud. To launch only Heat in standalone mode |
557 |
-you'll need the following settings in your `localrc` section |
|
557 |
+you'll need the following settings in your ``localrc`` section |
|
558 | 558 |
|
559 | 559 |
:: |
560 | 560 |
|
... | ... |
@@ -590,14 +591,14 @@ Xenserver |
590 | 590 |
~~~~~~~~~ |
591 | 591 |
|
592 | 592 |
If you would like to use Xenserver as the hypervisor, please refer to |
593 |
-the instructions in `./tools/xen/README.md`. |
|
593 |
+the instructions in ``./tools/xen/README.md``. |
|
594 | 594 |
|
595 | 595 |
Cells |
596 | 596 |
~~~~~ |
597 | 597 |
|
598 | 598 |
`Cells <http://wiki.openstack.org/blueprint-nova-compute-cells>`__ is |
599 | 599 |
an alternative scaling option. To setup a cells environment add the |
600 |
-following to your `localrc` section: |
|
600 |
+following to your ``localrc`` section: |
|
601 | 601 |
|
602 | 602 |
:: |
603 | 603 |
|
... | ... |
@@ -50,7 +50,7 @@ the host: |
50 | 50 |
parm: nested:bool |
51 | 51 |
|
52 | 52 |
Start your VM, now it should have KVM capabilities -- you can verify |
53 |
-that by ensuring `/dev/kvm` character device is present. |
|
53 |
+that by ensuring ``/dev/kvm`` character device is present. |
|
54 | 54 |
|
55 | 55 |
|
56 | 56 |
Configure Nested KVM for AMD-based Machines |
... | ... |
@@ -97,7 +97,7 @@ To make the above value persistent across reboots, add an entry in |
97 | 97 |
Expose Virtualization Extensions to DevStack VM |
98 | 98 |
----------------------------------------------- |
99 | 99 |
|
100 |
-Edit the VM's libvirt XML configuration via `virsh` utility: |
|
100 |
+Edit the VM's libvirt XML configuration via ``virsh`` utility: |
|
101 | 101 |
|
102 | 102 |
:: |
103 | 103 |
|
... | ... |
@@ -115,10 +115,10 @@ Ensure DevStack VM is Using KVM |
115 | 115 |
------------------------------- |
116 | 116 |
|
117 | 117 |
Before invoking ``stack.sh`` in the VM, ensure that KVM is enabled. This |
118 |
-can be verified by checking for the presence of the file `/dev/kvm` in |
|
118 |
+can be verified by checking for the presence of the file ``/dev/kvm`` in |
|
119 | 119 |
your VM. If it is present, DevStack will default to using the config |
120 |
-attribute `virt_type = kvm` in `/etc/nova.conf`; otherwise, it'll fall |
|
121 |
-back to `virt_type=qemu`, i.e. plain QEMU emulation. |
|
120 |
+attribute ``virt_type = kvm`` in ``/etc/nova.conf``; otherwise, it'll fall |
|
121 |
+back to ``virt_type=qemu``, i.e. plain QEMU emulation. |
|
122 | 122 |
|
123 | 123 |
Optionally, to explicitly set the type of virtualization, to KVM, by the |
124 | 124 |
libvirt driver in nova, the below config attribute can be used in |
... | ... |
@@ -131,7 +131,7 @@ DevStack's ``local.conf``: |
131 | 131 |
|
132 | 132 |
Once DevStack is configured successfully, verify if the Nova instances |
133 | 133 |
are using KVM by noticing the QEMU CLI invoked by Nova is using the |
134 |
-parameter `accel=kvm`, e.g.: |
|
134 |
+parameter ``accel=kvm``, e.g.: |
|
135 | 135 |
|
136 | 136 |
:: |
137 | 137 |
|
... | ... |
@@ -170,8 +170,8 @@ nova, neutron) |
170 | 170 |
**Compute Nodes** |
171 | 171 |
|
172 | 172 |
In this example, the nodes that will host guest instances will run |
173 |
-the `neutron-openvswitch-agent` for network connectivity, as well as |
|
174 |
-the compute service `nova-compute`. |
|
173 |
+the ``neutron-openvswitch-agent`` for network connectivity, as well as |
|
174 |
+the compute service ``nova-compute``. |
|
175 | 175 |
|
176 | 176 |
DevStack Configuration |
177 | 177 |
---------------------- |
... | ... |
@@ -256,16 +256,16 @@ compute node 1. |
256 | 256 |
Q_L3_ENABLED=False |
257 | 257 |
|
258 | 258 |
Compute node 2's configuration will be exactly the same, except |
259 |
-`HOST_IP` will be `10.0.0.4` |
|
259 |
+``HOST_IP`` will be ``10.0.0.4`` |
|
260 | 260 |
|
261 | 261 |
When DevStack is configured to use provider networking (via |
262 |
-`Q_USE_PROVIDER_NETWORKING` is True and `Q_L3_ENABLED` is False) - |
|
262 |
+``Q_USE_PROVIDER_NETWORKING`` is True and ``Q_L3_ENABLED`` is False) - |
|
263 | 263 |
DevStack will automatically add the network interface defined in |
264 |
-`PUBLIC_INTERFACE` to the `OVS_PHYSICAL_BRIDGE` |
|
264 |
+``PUBLIC_INTERFACE`` to the ``OVS_PHYSICAL_BRIDGE`` |
|
265 | 265 |
|
266 | 266 |
For example, with the above configuration, a bridge is |
267 |
-created, named `br-ex` which is managed by Open vSwitch, and the |
|
268 |
-second interface on the compute node, `eth1` is attached to the |
|
267 |
+created, named ``br-ex`` which is managed by Open vSwitch, and the |
|
268 |
+second interface on the compute node, ``eth1`` is attached to the |
|
269 | 269 |
bridge, to forward traffic sent by guest VMs. |
270 | 270 |
|
271 | 271 |
Miscellaneous Tips |
... | ... |
@@ -307,7 +307,7 @@ Configuring Extension Drivers for the ML2 Plugin |
307 | 307 |
------------------------------------------------ |
308 | 308 |
|
309 | 309 |
Extension drivers for the ML2 plugin are set with the variable |
310 |
-`Q_ML2_PLUGIN_EXT_DRIVERS`, and includes the 'port_security' extension |
|
310 |
+``Q_ML2_PLUGIN_EXT_DRIVERS``, and includes the 'port_security' extension |
|
311 | 311 |
by default. If you want to remove all the extension drivers (even |
312 |
-'port_security'), set `Q_ML2_PLUGIN_EXT_DRIVERS` to blank. |
|
312 |
+'port_security'), set ``Q_ML2_PLUGIN_EXT_DRIVERS`` to blank. |
|
313 | 313 |
|