Fix documentation files

The README.rst was incorrectly pointing at this repository as being
Neutron. Fix this and a few other nits in there.

Also, the TESTING.rst file was incorrectly poining to run_tests.sh,
which this repository does not support.

Change-Id: I18c2e9369648b3f6dfe5d2899d3710efe9e2e391

README.rst

@@ -1,30 +1,21 @@
 Welcome!
 ========
 
-You have come across a cloud computing network fabric controller. It has
-identified itself as "Neutron." It aims to tame your (cloud) networking!
+This is the external, decomposed plugin library for the OpenDaylight ML2
+MechanismDriver. This is the backend code which handles communication with
+OpenDaylight.
 
 External Resources:
 ===================
 
-The homepage for Neutron is: http://launchpad.net/neutron.  Use this
-site for asking for help, and filing bugs. Code is available on
-git.openstack.org at <http://git.openstack.org/cgit/openstack/neutron>.
+The OpenDaylight homepage:
+   http://www.opendaylight.org/
 
-The latest and most in-depth documentation on how to use Neutron is
-available at: <http://docs.openstack.org>. This includes:
+The Launchpad page for stackforge/networking-odl:
+   https://launchpad.net/networking-odl
 
-Neutron Administrator Guide
-   http://docs.openstack.org/admin-guide-cloud/content/ch_networking.html
+File bugs for this project here:
+   https://bugs.launchpad.net/networking-odl
 
-Neutron API Reference:
-   http://docs.openstack.org/api/openstack-network/2.0/content/
-
-Current Neutron developer documentation is available at:
-   http://wiki.openstack.org/NeutronDevelopment
-
-For help on usage and hacking of Neutron, please send mail to
-<mailto:openstack-dev@lists.openstack.org>.
-
-For information on how to contribute to Neutron, please see the
-contents of the CONTRIBUTING.rst file.
+The Neutron homepage:
+   http://launchpad.net/neutron.

TESTING.rst

@@ -1,5 +1,5 @@
 Testing Neutron
-=============================================================
+===============
 
 Overview
 --------
@@ -42,10 +42,10 @@ for DevStack at https://github.com/bcwaldon/vagrant_devstack.
 Running unit tests
 ------------------
 
-There are three mechanisms for running tests: run_tests.sh, tox,
-and nose. Before submitting a patch for review you should always
-ensure all test pass; a tox run is triggered by the jenkins gate
-executed on gerrit for each patch pushed for review.
+There are two mechanisms for running tests: tox, and nose. Before submitting
+a patch for review you should always ensure all test pass; a tox run is
+triggered by the jenkins gate executed on gerrit for each patch pushed for
+review.
 
 With these mechanisms you can either run the tests in the standard
 environment or create a virtual environment to run them in.
@@ -54,15 +54,6 @@ By default after running all of the tests, any pep8 errors
 found in the tree will be reported.
 
 
-With `run_tests.sh`
-~~~~~~~~~~~~~~~~~~~
-
-You can use the `run_tests.sh` script in the root source directory to execute
-tests in a virtualenv::
-
-    ./run_tests -V
-
-
 With `nose`
 ~~~~~~~~~~~
 
@@ -100,16 +91,6 @@ Neutron source code::
 
     tox
 
-To run functional tests that do not require sudo privileges or
-specific-system dependencies::
-
-    tox -e functional
-
-To run all the functional tests in an environment that has been configured
-by devstack to support sudo and system-specific dependencies::
-
-    tox -e dsvm-functional
-
 For more information on the standard Tox-based test infrastructure used by
 OpenStack and how to do some common test/debugging procedures with Testr,
 see this wiki page:
@@ -133,10 +114,6 @@ class separating it from the module path with a colon.
 For example, the following would run only the JSONV2TestCase tests from
 neutron/tests/unit/test_api_v2.py::
 
-      $ ./run_tests.sh neutron.tests.unit.test_api_v2.JSONV2TestCase
-
-or::
-
       $ tox -e py27 neutron.tests.unit.test_api_v2.JSONV2TestCase
 
 Adding more tests
@@ -148,16 +125,11 @@ need to be covered by unit and functional tests.
 To get a grasp of the areas where tests are needed, you can check
 current coverage by running::
 
-    $ ./run_tests.sh -c
+    $ tox -ecover
 
 Debugging
 ---------
 
-By default, calls to pdb.set_trace() will be ignored when tests
-are run.  For pdb statements to work, invoke run_tests as follows::
-
-    $ ./run_tests.sh -d [test module path]
-
 It's possible to debug tests in a tox environment::
 
     $ tox -e venv -- python -m testtools.run [test module path]
@@ -181,23 +153,6 @@ Editable mode ensures that changes made to the source tree are
 automatically reflected in the venv, and that such changes are not
 overwritten during the next tox run.
 
-Post-mortem debugging
-~~~~~~~~~~~~~~~~~~~~~
-
-Setting OS_POST_MORTEM_DEBUGGER in the shell environment will ensure
-that the debugger .post_mortem() method will be invoked on test failure::
-
-    $ OS_POST_MORTEM_DEBUGGER=pdb ./run_tests.sh -d [test module path]
-
-Supported debuggers are pdb, and pudb. Pudb is full-screen, console-based
-visual debugger for Python which let you inspect variables, the stack,
-and breakpoints in a very visual way, keeping a high degree of compatibility
-with pdb::
-
-    $ ./.venv/bin/pip install pudb
-
-    $ OS_POST_MORTEM_DEBUGGER=pudb ./run_tests.sh -d [test module path]
-
 References
 ==========