diff --git a/doc/source/architecture.rst b/doc/source/architecture.rst
index 97b45ad42..63bde2ac5 100644
--- a/doc/source/architecture.rst
+++ b/doc/source/architecture.rst
@@ -5,12 +5,6 @@
 =====================
 
 .. index::
-   single: agent; architecture
-   double: compute agent; architecture
-   double: collector; architecture
-   double: data store; architecture
-   double: database; architecture
-   double: API; architecture
 
 High-Level Architecture
 =======================
@@ -25,32 +19,27 @@ Evaluating the data
 Alarming Service
 ----------------
 
-The alarming component of Aodh, first delivered in the Havana
-version, allows you to set alarms based on threshold evaluation for a
-collection of samples. An alarm can be set on a single meter, or on a
-combination. For example, you may want to trigger an alarm when the memory
-consumption reaches 70% on a given instance if the instance has been up for
-more than 10 min. To setup an alarm, you will call
+The alarming component of Aodh, first delivered in Ceilometer service during
+Havana development cycle then split out to this independent project in Liberty
+development cycle, allows you to set alarms based on threshold evaluation for
+a collection of samples or a dedicate event. An alarm can be set on a single
+meter, or on a combination. For example, you may want to trigger an alarm when
+the memory consumption reaches 70% on a given instance if the instance has been
+up for more than 10 min. To setup an alarm, you will call
 :ref:`Aodh's API server <alarms-api>` specifying the alarm conditions and
 an action to take.
 
 Of course, if you are not administrator of the cloud itself, you can only set
 alarms on meters for your own components.
 
-There can be multiple form of actions, but two have been implemented so far:
+There can be multiple form of actions, but only several actions have been
+implemented so far:
 
 1. :term:`HTTP callback`: you provide a URL to be called whenever the alarm has
    been set off. The payload of the request contains all the details of why the
    alarm was triggered.
 2. :term:`log`: mostly useful for debugging, stores alarms in a log file.
-
-For more details on this, we recommend that you read the blog post by
-Mehdi Abaakouk `Autoscaling with Heat and Ceilometer`_. Particular attention
-should be given to the section "Some notes about deploying alarming" as the
-database setup (using a separate database from the one used for metering)
-will be critical in all cases of production deployment.
-
-.. _Autoscaling with Heat and Ceilometer: http://techs.enovance.com/5991/autoscaling-with-heat-and-ceilometer
+3. :term:`zaqar`: Send notification to messaging service via Zaqar API.
 
 Alarm Rules
 ===========
diff --git a/doc/source/glossary.rst b/doc/source/glossary.rst
index de3d43e07..d635531dd 100644
--- a/doc/source/glossary.rst
+++ b/doc/source/glossary.rst
@@ -41,6 +41,12 @@
      Logging is one of the alarm actions that is useful mostly for debugging,
      it stores the alarms in a log file.
 
+   zaqar
+     According to `Zaqar Developer Documentation`_:
+
+       Zaqar is a multi-tenant cloud messaging and notification service for web
+       and mobile developers.
+
    project
      The OpenStack tenant or project.
 
@@ -51,3 +57,4 @@
      An OpenStack user.
 
 .. [#] http://en.wikipedia.org/wiki/Ceilometer
+.. _Zaqar Developer Documentation: http://docs.openstack.org/developer/zaqar/
diff --git a/doc/source/testing.rst b/doc/source/testing.rst
index e3096f84c..b7d81a3c7 100644
--- a/doc/source/testing.rst
+++ b/doc/source/testing.rst
@@ -35,11 +35,7 @@ run through tox_.
    $ sudo yum install mongodb
    $ sudo yum install mariadb-devel.x86_64
 
-3. Install the test dependencies::
-
-   $ sudo pip install -e /opt/stack/aodh[test]
-
-4. Run the unit and code-style tests::
+3. Run the unit and code-style tests::
 
    $ cd /opt/stack/aodh
    $ tox -e py27,pep8
@@ -62,16 +58,16 @@ run through tox_.
    For reference, the ``debug`` tox environment implements the instructions
    here: https://wiki.openstack.org/wiki/Testr#Debugging_.28pdb.29_Tests
 
-5. There is a growing suite of tests which use a tool called `gabbi`_ to
+4. There is a growing suite of tests which use a tool called `gabbi`_ to
    test and validate the behavior of the Aodh API. These tests are run
-   when using the usual ``py27`` tox target but if desired they can be run by
-   themselves::
+   when using the usual ``functional`` tox target but if desired they can be
+   run by themselves::
 
    $ tox -e gabbi
 
    The YAML files used to drive the gabbi tests can be found in
-   ``aodh/tests/gabbi/gabbits``. If you are adding to or adjusting the
-   API you should consider adding tests here.
+   ``aodh/tests/functional/gabbi/gabbits``. If you are adding to or adjusting
+   the API you should consider adding tests here.
 
 .. _gabbi: https://gabbi.readthedocs.org/
 
diff --git a/doc/source/webapi/index.rst b/doc/source/webapi/index.rst
index f8891188e..a3a2c03a5 100644
--- a/doc/source/webapi/index.rst
+++ b/doc/source/webapi/index.rst
@@ -9,7 +9,7 @@
 
 You can get API version list via request to endpoint root path. For example::
 
-  curl -H "X-AUTH-TOKEN: fa2ec18631f94039a5b9a8b4fe8f56ad" http://127.0.0.1:8777
+  curl -H "X-AUTH-TOKEN: fa2ec18631f94039a5b9a8b4fe8f56ad" http://127.0.0.1:8042
 
 Sample response::
 
@@ -20,7 +20,7 @@ Sample response::
                   "id": "v2",
                   "links": [
                       {
-                          "href": "http://127.0.0.1:8777/v2",
+                          "href": "http://127.0.0.1:8042/v2",
                           "rel": "self"
                       },
                       {