update document

Change-Id: Ie40b2e04e59d4763f1eeef46feb5081ecefc24f2

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
+The alarming component of Aodh, first delivered in Ceilometer service during
-version, allows you to set alarms based on threshold evaluation for a
+Havana development cycle then split out to this independent project in Liberty
-collection of samples. An alarm can be set on a single meter, or on a
+development cycle, allows you to set alarms based on threshold evaluation for
-combination. For example, you may want to trigger an alarm when the memory
+a collection of samples or a dedicate event. An alarm can be set on a single
-consumption reaches 70% on a given instance if the instance has been up for
+meter, or on a combination. For example, you may want to trigger an alarm when
-more than 10 min. To setup an alarm, you will call
+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.
-
+3. :term:`zaqar`: Send notification to messaging service via Zaqar API.
-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
 
 Alarm Rules
 ===========

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/

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::
+3. Run the unit and code-style tests::
-
-   $ sudo pip install -e /opt/stack/aodh[test]
-
-4. 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
+   when using the usual ``functional`` tox target but if desired they can be
-   themselves::
+   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
+   ``aodh/tests/functional/gabbi/gabbits``. If you are adding to or adjusting
-   API you should consider adding tests here.
+   the API you should consider adding tests here.
 
 .. _gabbi: https://gabbi.readthedocs.org/
 

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"
                       },
                       {