diff --git a/doc/source/usage.rst b/doc/source/usage.rst
index 153fc638..c934a312 100644
--- a/doc/source/usage.rst
+++ b/doc/source/usage.rst
@@ -72,23 +72,28 @@ files.
 Launching and controlling services
 ==================================
 
-oslo_service.service module provides tools for launching OpenStack services and controlling their lifecycles.
+oslo_service.service module provides tools for launching OpenStack
+services and controlling their lifecycles.
 
-A service is an instance of any class that subclasses :py:class:`oslo_service.service.ServiceBase`.
-:py:class:`ServiceBase <oslo_service.service.ServiceBase>` is an abstract class that defines an interface every
-service should implement. :py:class:`oslo_service.service.Service` can serve as a base for constructing new services.
+A service is an instance of any class that
+subclasses :py:class:`oslo_service.service.ServiceBase`.
+:py:class:`ServiceBase <oslo_service.service.ServiceBase>` is an
+abstract class that defines an interface every
+service should implement. :py:class:`oslo_service.service.Service` can
+serve as a base for constructing new services.
 
 Launchers
 ~~~~~~~~~
 
 oslo_service.service module provides two launchers for running services:
 
-    * :py:class:`oslo_service.service.ServiceLauncher` - used for running one or more service in
-      a parent process.
-    * :py:class:`oslo_service.service.ProcessLauncher` - forks a given number of workers in which
-      service(s) are then started.
+    * :py:class:`oslo_service.service.ServiceLauncher` - used for
+      running one or more service in a parent process.
+    * :py:class:`oslo_service.service.ProcessLauncher` - forks a given
+      number of workers in which service(s) are then started.
 
-It is possible to initialize whatever launcher is needed and then launch a service using it.
+It is possible to initialize whatever launcher is needed and then
+launch a service using it.
 
 ::
 
@@ -104,9 +109,10 @@ It is possible to initialize whatever launcher is needed and then launch a servi
     process_launcher = service.ProcessLauncher(CONF, wait_interval=1.0)
     process_launcher.launch_service(service.Service(), workers=2)
 
-Or one can simply call :func:`oslo_service.service.launch` which will automatically pick an appropriate launcher
-based on a number of workers that are passed to it (ServiceLauncher in case workers=1 or None and ProcessLauncher in
-other case).
+Or one can simply call :func:`oslo_service.service.launch` which will
+automatically pick an appropriate launcher based on a number of workers that
+are passed to it (ServiceLauncher in case workers=1 or None and
+ProcessLauncher in other case).
 
 ::
 
@@ -117,24 +123,30 @@ other case).
 
     launcher = service.launch(CONF, service.Service(), workers=3)
 
-*NOTE:* Please be informed that it is highly recommended to use no more than one instance of ServiceLauncher and
-ProcessLauncher classes per process.
+*NOTE:* Please be informed that it is highly recommended to use no
+more than one instance of ServiceLauncher and ProcessLauncher classes
+per process.
 
 Signal handling
 ~~~~~~~~~~~~~~~
 
-oslo_service.service provides handlers for such signals as SIGTERM, SIGINT and SIGHUP.
+oslo_service.service provides handlers for such signals as SIGTERM, SIGINT
+and SIGHUP.
 
-SIGTERM is used for graceful termination of services. This can allow a server to wait for all clients to close
-connections while rejecting new incoming requests. To force instantaneous termination SIGINT signal must be sent.
+SIGTERM is used for graceful termination of services. This can allow a
+server to wait for all clients to close connections while rejecting new
+incoming requests. To force instantaneous termination SIGINT signal must
+be sent.
 
-On receiving SIGHUP configuration files are reloaded and a service is being reset and started again. Then all child
-workers are gracefully stopped using SIGTERM and workers with new configuration are spawned. Thus, SIGHUP can be used
-for changing config options on the go.
+On receiving SIGHUP configuration files are reloaded and a service
+is being reset and started again. Then all child workers are gracefully
+stopped using SIGTERM and workers with new configuration are
+spawned. Thus, SIGHUP can be used for changing config options on the go.
 
 *NOTE:* SIGHUP is not supported on Windows.
 
-Below is the example of a service with a reset method that allows reloading logging options by sending a SIGHUP.
+Below is the example of a service with a reset method that allows reloading
+logging options by sending a SIGHUP.
 
 ::
 
diff --git a/test-requirements.txt b/test-requirements.txt
index 8fabf398..73075566 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -6,8 +6,9 @@ hacking<0.11,>=0.10.0
 mock>=1.2
 oslotest>=1.10.0 # Apache-2.0
 
-# These are needed for docs generation
+# These are needed for docs generation/testing
 oslosphinx>=2.5.0 # Apache-2.0
 sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2
+doc8 # Apache-2.0
 
 coverage>=3.6
diff --git a/tox.ini b/tox.ini
index 4f2a0bfc..deffcb8a 100644
--- a/tox.ini
+++ b/tox.ini
@@ -19,6 +19,11 @@ commands = python setup.py testr --slowest --testr-args='{posargs}'
 [testenv:pep8]
 commands = flake8
 
+[testenv:py27]
+commands =
+    python setup.py testr --slowest --testr-args='{posargs}'
+    doc8 --ignore-path "doc/source/history.rst" doc/source
+
 [testenv:py34]
 commands =
   python -m testtools.run \