doc: formatting fixes

Signed-off-by: Sol Jerome <solj@ices.utexas.edu>

git-svn-id: https://svn.mcs.anl.gov/repos/bcfg/trunk/bcfg2@5738 ce84e21b-d406-0410-9b95-82705330c041

2 files changed, 31 insertions, 12 deletions

diff --git a/doc/client/debugging.txt b/doc/client/debugging.txt
index c99e73c3e..06e388840 100644
--- a/doc/client/debugging.txt
+++ b/doc/client/debugging.txt
@@ -6,9 +6,13 @@
 Client Debugging
 ================
 
-When working on the Bcfg2 client, it is helpful to employ a few specific techniques to isolate and remedy problems.
+When working on the Bcfg2 client, it is helpful to employ a few specific
+techniques to isolate and remedy problems.
 
-First, running the client with the -f flag allows configuration from a local file, rather than querying the server. This helps rule out server configuration problems, and allows for rapid development. For example: `bcfg2 -f test-config.conf` with the following test-config.conf:
+First, running the client with the -f flag allows configuration from a
+local file, rather than querying the server. This helps rule out server
+configuration problems, and allows for rapid development. For example:
+``bcfg2 -f test-config.conf`` with the following test-config.conf:
 
 .. code-block:: rst
 
@@ -18,7 +22,15 @@ First, running the client with the -f flag allows configuration from a local fil
         </Bundle>
     </Configuration>
 
-Next, it is important to look at the interactive mode. This is similar to the interactive mode on the server and provides an interactive Python interpreter with which one may manipulate all the objects in the client. It will setup all the infrastructure so you will have the appropriate objects to play with. It will run the client through once, then present you with an interpreter. Try it out with: `python -i /usr/bin/bcfg2` or, for more fun, a local config file and also enable Debugging and Verbose output with `-d` and `-v`, yielding `python -i /usr/bin/bcfg2 -d -v -f test-config.conf`
-
-Now we just explore; use `dir()` to examine different objects in the client, or run a reconfiguration again by calling `client.run()`
-
+Next, it is important to look at the interactive mode. This is similar
+to the interactive mode on the server and provides an interactive
+Python interpreter with which one may manipulate all the objects in
+the client. It will setup all the infrastructure so you will have the
+appropriate objects to play with. It will run the client through once,
+then present you with an interpreter. Try it out with: ``python -i
+/usr/bin/bcfg2`` or, for more fun, a local config file and also enable
+Debugging and Verbose output with `-d` and `-v`, yielding ``python -i
+/usr/bin/bcfg2 -d -v -f test-config.conf``.
+
+Now we just explore; use ``dir()`` to examine different objects in the
+client, or run a reconfiguration again by calling `client.run()`
diff --git a/doc/client/index.txt b/doc/client/index.txt
index 438e43dcd..d0e7bd9a6 100644
--- a/doc/client/index.txt
+++ b/doc/client/index.txt
@@ -6,14 +6,21 @@ The Bcfg2 Client
 ================
 
 The Bcfg2 client is responsible for determining what reconfiguration
-operations must be undertaken on the client, but does not perform any
-processing of the target configuration description. We chose this
+operations must be undertaken on the client, but does not perform
+any processing of the target configuration description. We chose this
 architecture, as opposed to one with a smarter client, for a few reasons:
 
-* Client failure forces administrators to perform an O(n) reconfiguration operation. Simpler code is easier to debug and maintain.
-* Minimize the bootstrap size; a complicated client can require more aspects of the system to function in order for reconfiguration to work.
-* Isolate configuration generation functionality on the server, where it can be readily observed. This is the most complicated task that Bcfg2 performs.
-* The results of the configuration process fit a fairly simple model. We wanted to validate it. The result is that Bcfg2 has a programmable deployment engine that can be driven by anything that writes a compatible configuration description.
+* Client failure forces administrators to perform an O(n) reconfiguration
+  operation. Simpler code is easier to debug and maintain.
+* Minimize the bootstrap size; a complicated client can require more
+  aspects of the system to function in order for reconfiguration to work.
+* Isolate configuration generation functionality on the server, where
+  it can be readily observed. This is the most complicated task that
+  Bcfg2 performs.
+* The results of the configuration process fit a fairly simple model. We
+  wanted to validate it. The result is that Bcfg2 has a programmable
+  deployment engine that can be driven by anything that writes a
+  compatible configuration description.
 
 .. toctree::
    :maxdepth: 2