Beautify, correct URLs in documentation files

- Beautify, re-indent, format code in a lot of doc files
- Use relative URLs instead of absolute github URLs
- Some absolute github urls are not corrected yet:
    + URL for enabling vitrage in devstack
    + URL for enabling vitrage in horizon
- Update year number in doc/source/config.py from 2013 to 2016

My thought: We should have a blueprint
    to create more concise and easy to access like other project
    (nova: http://docs.openstack.org/developer/nova/).
    Currently, that site for vitrage has not existed yet.

Notes: Change github URLs to relative URLs
    (or absolute URLs in docs.openstack.org/developers)
    will not work correctly
    if we do not have official documentation site.
    Hence, other people cannot follow the link to html page
    if they read vitrage documentation in github mirror.

Change-Id: Ifff8355c7e5291f68a7592d1617644053d790d5e

README.rst

@@ -8,12 +8,12 @@ Vitrage is the OpenStack RCA (Root Cause Analysis) Service for organizing, analy
 
 Enabling Vitrage in DevStack
 ----------------------------
-see `README file <https://github.com/openstack/vitrage/blob/master/devstack/README.rst/>`_
+More details in: `README file <devstack/README.rst>`_
 
 Project Resources
 -----------------
 
-* wiki page: https://wiki.openstack.org/wiki/Vitrage
+* Wiki page: https://wiki.openstack.org/wiki/Vitrage
 * Launchpad: https://launchpad.net/vitrage
 * Source: http://git.openstack.org/cgit/openstack/vitrage
 

doc/source/add-new-datasource.rst

@@ -9,19 +9,19 @@ In order to add a new datasource to Vitrage do the following steps:
 
  1. Have your datasource enclosed in a package with the datasources' name and
     put it under 'vitrage.datasources', For example:
-    vitrage.datasource.cinder.volume.
+    ``vitrage.datasource.cinder.volume``.
  2. Under your datasource package, have both your datasources' driver class
     and your datasources' transformer class. See below for details on those
     classes.
- 3. Under your datasources' package __init__.py you must import cfg
+ 3. Under your datasources' package ``__init__.py`` you must import ``cfg``
-    from oslo_config and declare a list named OPTS. Under OPTS, you can define
+    from ``oslo_config`` and declare a list named ``OPTS``. Under ``OPTS``, you can define
-    your needed options using the oslo_config.cfg module.
+    your needed options using the ``oslo_config.cfg`` module.
     There are three options you must have:
 
     a. Driver and transformer with the path to your driver and transformer
        classes respectively.
-    b. update_method property that describes the type of update mechanism for
+    b. ``update_method`` property that describes the type of update mechanism for
-       this datasource. The options are: push, pull or none.
+       this datasource. The options are (string): push, pull or none.
     c. In addition to those three, you may add any other configuration options
        you may need for your datasource.
 
@@ -32,19 +32,18 @@ In order to add a new datasource to Vitrage do the following steps:
     devstack is installed, you need to add it to the 'types' property in the
     datasources section in the configuration. To do so, do the following:
 
-    a. add the datasource name to the types property in the "devstack.settings"
+    a. add the datasource name to the types property in the ``devstack.settings``
        file.
     b. if the datasource is not one of the main and basic projects of devstack,
-       add the following data in the "devstack.plugin.sh" file":
+       add the following data in the ``devstack.plugin.sh`` file":
 
-       # remove <datasource_name> vitrage datasource if <datasource_name>
+    .. code:: bash
-       datasource not installed
 
-       if ! is_service_enabled <datasource_name>; then
+        # remove <datasource_name> vitrage datasource if <datasource_name> datasource not installed
 
-          disable_vitrage_datasource <datasource_name>
+        if ! is_service_enabled <datasource_name>; then
-
+            disable_vitrage_datasource <datasource_name>
-       fi
+        fi
  6. You are done!
 
 
@@ -56,14 +55,14 @@ Entities in this context refer both to resources (physical, virtual,
 applicative) and alarms (Aodh, Nagios, Zabbix, Monasca, etc.)
 The datasource has two modes of action:
 
- 1. get_all (snapshot): Query all entities and send events to the vitrage
+ 1. ``get_all`` (snapshot): Query all entities and send events to the vitrage
     events queue.
     When done for the first time, send an "end" event to inform it has finished
     the get_all for the datasource (because it is done asynchronously).
- 2. notify: Send an event to the vitrage events queue upon any change.
+ 2. ``notify``: Send an event to the vitrage events queue upon any change.
     This can be done in two ways:
 
-    a. Built in polling mechanism called get_changes.
+    a. Built in polling mechanism called ``get_changes``.
     b. Built in pushing mechanism using the oslo bus.
 
 A driver should inherit from 'vitrage.datasources.driver_base.DriverBase' class
@@ -88,7 +87,7 @@ _________________
 The Transformer class understands the specific entity details and outputs a
 tuple with the following details:
 
- 1. The vertex with its new details to be added / updated / deleted.
+ 1. The vertex with its new details to be added/updated/deleted.
  2. List of tuples where each tuple consists of:
 
     a. Neighbor vertex with it's partial data so vitrage will know to where
@@ -97,7 +96,7 @@ tuple with the following details:
 
 Note that for every driver there should be a matching Transformer.
 A transformer should inherit from
-'vitrage.datasoures.transformer_base.TransformerBase' class and
+``vitrage.datasoures.transformer_base.TransformerBase`` class and
 must implement the following methods:
 
 +----------------------------------+------------------------------------+----------------------------------------+
@@ -138,7 +137,7 @@ Holds the following fields:
 
 **Example**
 
-Datasource __init__.py OPTS:
+Datasource ``__init__.py OPTS``:
 
 .. code:: python
 
@@ -168,23 +167,25 @@ Datasource __init__.py OPTS:
 Instantiation flow
 ------------------
 
-Now, when loading Vitrage, vitrage.datasources.launcher.Launcher
+Now, when loading Vitrage, ``vitrage.datasources.launcher.Launcher``
 will get instantiated and will register all of the datasources
-into Vitrage. Note, that if you want your datasource to also run as a
+into Vitrage. **Note**: if you want your datasource to also run as a
 service i.e. get changes every <interval> you need to set under your
-datasources' OPTS an Integer option named 'changes_interval'.
+datasources ``OPTS`` an ``Integer`` option named ``changes_interval``.
-Additionally, vitrage.entity_graph.transformer_manager.TransformerManager
+
+Additionally, ``vitrage.entity_graph.transformer_manager.TransformerManager``
 will get instantiated and will register all of the datasources transformers
 into Vitrage.
+
 These two steps are using your previously configured driver and
-transformer path options under your datasources' package __init__.OPTS.
+transformer path options under your datasources' package ``__init__.OPTS``.
 
 
 Datasource Configuration Options
 --------------------------------
 
-Any option your datasource defined can be accessed using oslo_config.cfg
+Any option your datasource defined can be accessed using ``oslo_config.cfg``
-or by configuring vitrage.conf.
+or by configuring ``vitrage.conf``.
 
 **Example**
 
@@ -195,26 +196,23 @@ or by configuring vitrage.conf.
 
 **Example**
 
-/etc/vitrage/vitrage.conf
+.. code::
 
+    # /etc/vitrage/vitrage.conf
     ...
-
     [datasources]
-
     snapshots_interval = 300
-
     # Names of supported plugins (list value)
-
+    types = nagios,zabbix,nova.host,nova.instance,nova.zone,static_physical,aodh,cinder.volume,neutron.network,neutron.port,heat.stack
-    types = nova.host,nova.instance,nova.zone,static_physical,nagios,aodh,cinder.volume,neutron.network,neutron.port,heat.stack
-
 
     [zabbix]
-
+    url = http://<ip>/zabbix
-    url = http://135.248.18.30
-
     password = zabbix
-
     user = admin
-
     config_file = /etc/vitrage/zabbix_conf.yaml
 
+    [nagios]
+    user = omdadmin
+    password = omd
+    url = http://<ip>:<port>/<site>/nagios/cgi-bin/status.cgi
+    config_file = /etc/vitrage/nagios_conf.yaml

doc/source/alarm-severity-config.rst

@@ -16,8 +16,9 @@ Since each data-source might represent severity differently, for each
 data-source we can supply it's own mapping to the aggregated severity supported
 in Vitrage. This way we can know which severity is more important.
 In addition we also normalize the severities for the horizon UI (called
-operational_severity) in order for the UI to know what color to show in
+``operational_severity``) in order for the UI to know what color to show in
 Horizon.
+
 This page explains how to handle this mapping for a given
 data-source.
 
@@ -66,12 +67,10 @@ Default Configuration
 Default configurations for alarms severities will be installed with Vitrage for
 all the pre-packaged data-sources.
 
-
-
-
 Format
 ++++++
-::
+
+.. code:: yaml
 
     category: ALARM
     values:
@@ -79,13 +78,11 @@ Format
           priority: <Alarm severity priority - an integer>
           original values:
             - name: <Original alarm severity name>
-              operational_value: <normalized alarm severity - from
+              operational_value: <normalized alarm severity - from OperationalAlarmSeverity class>
-                                  OperationalAlarmSeverity class>
             - name: ... # can list several severities for one aggregation
       - aggregated values:
           priority: ... # can list several aggregated severities
           ...
-
   ...
 
 
@@ -93,11 +90,14 @@ Example
 +++++++
 
 The following file will map alarm severities.
+
 For aggregated severity with priority 40 we have 2 severities and each one of
 them is mapped to operational severity CRITICAL.
+
 For aggregated severity with priority 30 we have 1 severity called WARNING and
 it is mapped to operational severity WARNING, etc...
-::
+
+.. code:: yaml
 
     category: ALARM
     values:

doc/source/conf.py

@@ -38,7 +38,7 @@ master_doc = 'index'
 
 # General information about the project.
 project = u'vitrage'
-copyright = u'2013, OpenStack Foundation'
+copyright = u'2016, OpenStack Foundation'
 
 # If true, '()' will be appended to :func: etc. cross-reference text.
 add_function_parentheses = True

doc/source/index.rst

@@ -25,7 +25,7 @@ Developer Guide
 ---------------
 
 .. toctree::
-   :maxdepth: 1 
+   :maxdepth: 1
 
    vitrage-first_steps
    vitrage-api
@@ -36,7 +36,7 @@ Design Documents
 ----------------
 
 .. toctree::
-   :maxdepth: 1 
+   :maxdepth: 1
 
    vitrage-graph-design
    scenario-evaluator

doc/source/installation-and-configuration.rst

@@ -2,26 +2,30 @@
 Installation
 ============
 
-In order to enable Vitrage:
+-------------------------------
+Enable Vitrage and data sources
+-------------------------------
 
-* `Enabling Vitrage in devstack <https://github.com/openstack/vitrage/blob/master/devstack/README.rst/>`_
+* `Enabling Vitrage in devstack <https://github.com/openstack/vitrage/blob/master/devstack/README.rst>`_
 
-* `Enabling Vitrage in horizon <https://github.com/openstack/vitrage-dashboard/blob/master/README.rst/>`_
+* `Enabling Vitrage in horizon <https://github.com/openstack/vitrage-dashboard/blob/master/README.rst>`_
 
-* `Nagios devstack installation <https://github.com/openstack/vitrage/blob/master/doc/source/nagios-devstack-installation.rst/>`_
+* `Nagios devstack installation <http://docs.openstack.org/developer/vitrage/nagios-devstack-installation.html>`_
+
+* `Zabbix devstack installation <http://docs.openstack.org/developer/vitrage/zabbix_vitrage.html>`_
 
 
 -------------
 Configuration
 -------------
 
-* `Nagios Plugin Configuration <https://github.com/openstack/vitrage/blob/master/doc/source/nagios-config.rst>`_
+* `Nagios Plugin Configuration <http://docs.openstack.org/developer/vitrage/nagios-config.html>`_
 
-* `Static Physical Plugin Configuration <https://github.com/openstack/vitrage/blob/master/doc/source/static-physical-config.rst>`_
+* `Static Physical Plugin Configuration <http://docs.openstack.org/developer/vitrage/static-physical-config.html>`_
 
-* `Resource State Configuration <https://github.com/openstack/vitrage/blob/master/doc/source/resource-state-config.rst>`_
+* `Resource State Configuration <http://docs.openstack.org/developer/vitrage/resource-state-config.html>`_
 
-* `Alarm State Configuration <https://github.com/openstack/vitrage/blob/master/doc/source/alarm-state-config.rst>`_
+* `Alarm Severity Configuration <http://docs.openstack.org/developer/vitrage/alarm-severity-config.html>`_
 
-* `Zabbix Configuration <https://github.com/openstack/vitrage/blob/master/doc/source/zabbix_vitrage.rst>`_
+* `Zabbix Configuration <http://docs.openstack.org/developer/vitrage/zabbix_vitrage.html>`_
 

doc/source/nagios-config.rst

@@ -5,7 +5,7 @@ Nagios Plugin Configuration
 Configure Access to Nagios
 --------------------------
 
-The following should be set in **/etc/vitrage/vitrage.conf**, under [nagios] section:
+The following should be set in ``/etc/vitrage/vitrage.conf``, under ``[nagios]`` section:
 
 +------------------+---------------------------------------------------------+-------------------------------+
 | Name             | Description                                             | Default Value                 |
@@ -31,9 +31,9 @@ Nagios access configuration - example
 When installing Nagios on devstack with IP 10.20.30.40, following
 the instructions here_, this would be the correct configuration:
 
-.. _here: https://github.com/openstack/vitrage/blob/master/doc/source/nagios-devstack-installation.rst
+.. _here: nagios-devstack-installation.html
 
- ::
+.. code::
 
   [nagios]
   user = omdadmin
@@ -54,7 +54,7 @@ to map each Nagios host to a Vitrage resource.
 Format
 ++++++
 
-::
+.. code ::
 
  nagios:
   - nagios_host: <Host as appears in Nagios>
@@ -64,7 +64,6 @@ Format
   - nagios_host: <Host as appears in Nagios>
     type: <resource type in Vitrage>
     name: <resource name in Vitrage>
-
   ...
 
 Note that for ease of use, there is support for wildcards in the "nagios_host"
@@ -79,7 +78,7 @@ Example 1
 The following example is for a system with two hosts. In nagios they are named
 *compute-0, compute-1*, and in nova they are named *host-1, host-2*.
 
-::
+.. code::
 
  nagios:
   - nagios_host: compute-0
@@ -94,15 +93,15 @@ Example 2
 +++++++++
 
 The following file will
- - map all Nagios hosts named host-*<some_suffix>* or *<some_prefix>*-devstack
+ - map all Nagios hosts named ``host-<some_suffix>`` or ``<some_prefix>-devstack``
-   to resources of type nova.host with the same name.
+   to resources of type ``nova.host`` with the same name.
- - map all Nagios hosts named instance-*<some_suffix>* to nova.instance
+ - map all Nagios hosts named ``instance-<some_suffix>`` to ``nova.instance``
    resources.
 
-Note how the *${nagios_host}* references the instantiation of the regex defined
+Note how the ``${nagios_host}`` references the instantiation of the regex defined
-in nagios_host.
+in ``nagios_host``.
 
-::
+.. code::
 
  nagios:
   - nagios_host: host-(.*)

doc/source/nagios-devstack-installation.rst

@@ -25,12 +25,14 @@ Installation
 ------------
 
 1. Update your repo to include the OMD key:
-   ::
+
+   .. code::
 
     wget -q "https://labs.consol.de/repo/stable/RPM-GPG-KEY" -O - | sudo apt-key add -
 
 2. Update your repo with the OMD site. For example, for ubuntu trusty release:
-   ::
+
+   .. code::
 
     sudo bash -c "echo 'deb https://labs.consol.de/repo/stable/ubuntu trusty main' >> /etc/apt/sources.list"
     sudo apt-get update
@@ -38,21 +40,24 @@ Installation
  For additional distros, see https://labs.consol.de/repo/stable/
 
 3. Install OMD
-   ::
+
+   .. code::
 
     sudo apt-get install omd
 
 4. Create a site for nagios with a name of your choosing, for example
-   "my_site".
+   ``my_site``.
-   ::
+
+   .. code::
 
     sudo omd create my_site
     sudo omd config my_site set APACHE_TCP_PORT 54321
     sudo omd config my_site set APACHE_TCP_ADDR 0.0.0.0
     sudo omd start  my_site
 
-   You can now access your Nagios site here: *http://<devstack_ip>:54321/my_site/omd*.
+   You can now access your Nagios site here: *http://<devstack_ip>:54321/my_site/omd/*.
-   ::
+
+   .. code::
 
     username: omdadmin
     password: omd
@@ -67,17 +72,19 @@ Installation
     - When using devstack, remember to stop omd apache2's sites
 
 5. Install the Check_MK agent on devstack VM:
-   ::
+
+   .. code::
 
     sudo apt-get install check-mk-agent
 
-6. Activate the Check_MK agent, by editing */etc/xinetd.d/check_mk* and
+6. Activate the Check_MK agent, by editing ``/etc/xinetd.d/check_mk`` and
    **setting "disable" to "no"**, and then run
-   ::
+
+   .. code::
 
     sudo service xinetd restart
 
-7. In your browser, go to *http://<devstack_ip>:<selected port>/my_site/omd*
+7. In your browser, go to *http://<devstack_ip>:<selected port>/my_site/omd/*
    and follow the instructions at this link_ (**"Configuring the first host and
    checks"** section) to configure the nagios host.
 
@@ -86,4 +93,4 @@ Installation
 8. *Vitrage Support.* With Nagios installed, you can now configure a datasource
    for it for Vitrage, by following the instructions here_.
 
-   .. _here: https://github.com/openstack/vitrage/blob/master/doc/source/nagios-config.rst
+   .. _here: nagios-config.html

doc/source/notifier-aodh-plugin.rst

@@ -5,6 +5,7 @@ Vitrage Notifier plugins - AODH
 Overview
 ========
 The Evaluator performs root cause analysis on the Vitrage Graph and may determine that an alarm should be created, deleted or otherwise updated.
+
 Other components are notified of such changes by the Vitrage Notifier service. Among others, Vitrage Notifier is responsible for handling Aodh Alarms.
 
 This document describes the implementation of Vitrage Notifier infrastructure and specifically notifying Aodh on Vitrage alarms.
@@ -49,15 +50,15 @@ Deduced Alarms bus notifications
 Vitrage Evaluator will create a deduced alarm, sending it to the data source queue
 Vitrage Evaluator will use the **vitrage.graph** message bus topic, and will post messages as follows:
 
- - message of type **vitrage.deduced_alarm.activate** :
+ - message of type ``vitrage.deduced_alarm.activate`` :
 
-   * name - is the alarm name in vitrage
+   * ``name`` - is the alarm name in vitrage
-   * severity - is the alarm severity
+   * ``severity`` - is the alarm severity
-   * affected_resource_id - is the openstack id of the resource on which the alarm was raised
+   * ``affected_resource_id`` - is the openstack id of the resource on which the alarm was raised
 
- - **vitrage.deduced_alarm.deactivate**
+ - ``vitrage.deduced_alarm.deactivate``
 
-   * id - is the alarm id
+   * ``id`` - is the alarm id
 
 Notifier
 ========
@@ -71,9 +72,9 @@ Aodh Plugin
 ===========
 Vitrage alarms should be reflected as possible in Aodh. The aodh plugin has ceilometer client by which it can send rest calls to aodh
 
-Handle vitrage.deduced_alarm.activate:
+Handle ``vitrage.deduced_alarm.activate``
--------------------------------------
+-----------------------------------------
-Create an event alarm with the specified severity, where the alarm name is vitrage_alarm_name+resource_id so to be unique
+Create an event alarm with the specified severity, where the alarm name is ``vitrage_alarm_name+resource_id`` so to be unique
 
  - Message does not contain aodh alarm id:
 
@@ -86,8 +87,8 @@ Create an event alarm with the specified severity, where the alarm name is vitra
 
    * plugin will **update** the aodh alarm status to alarm
 
-Handle vitrage.deduced_alarm.deactivate:
+Handle ``vitrage.deduced_alarm.deactivate``
----------------------------------------
+-------------------------------------------
-delete an event alarm with the specified id
+Delete an event alarm with the specified id
 
    * message will contain the aodh alarm id - plugin will **update** the alarm status to ok

doc/source/resource-state-config.rst

@@ -25,7 +25,7 @@ Configure Access to Resource State
 ----------------------------------
 
 The resource state configuration is handled via config files. The location of
-these files can be determined in **/etc/vitrage/vitrage.conf**. Under the
+these files can be determined in ``/etc/vitrage/vitrage.conf``. Under the
 [entity_graph] section, set:
 
 +------------------------+------------------------------------+----------------------------------+
@@ -65,27 +65,22 @@ Default Configuration
 Default configurations for resource states will be installed with Vitrage for
 all the pre-packaged data-sources.
 
-
-
-
 Format
 ++++++
-::
-
-    category: RESOURCE
-    values:
-      - aggregated values:
-          priority: <Resource state priority - an integer>
-          original values:
-            - name: <Original resource state name>
-              operational_value: <normalized resource state - from
-                                  OperationalResourceState class>
-            - name: ... # can list several states for one aggregation
-      - aggregated values:
-          priority: ... # can list several aggregated states
-          ...
 
+.. code:: yaml
 
+  category: RESOURCE
+  values:
+    - aggregated values:
+        priority: <Resource state priority - an integer>
+        original values:
+          - name: <Original resource state name>
+            operational_value: <normalized resource state - from OperationalResourceState class>
+          - name: ... # can list several states for one aggregation
+    - aggregated values:
+        priority: ... # can list several aggregated states
+        ...
   ...
 
 
@@ -93,12 +88,14 @@ Example
 +++++++
 
 The following file will map resource states.
+
 For aggregated state with priority 40 we have 4 states and each one of them is
 mapped to operational severity ERROR.
+
 For aggregated state with priority 30 we have 6 states and each one of them is
 mapped to operational severity TRANSIENT, etc...
 
-::
+.. code :: yaml
 
   category: RESOURCE
     values:

doc/source/scenario-evaluator.rst

@@ -88,7 +88,7 @@ Template Loading
 Scenarios are written up in configuration files called *templates*. The format
 and specification of these can be seen here_.
 
-.. _here: https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-template-format.rst
+.. _here: vitrage-template-format.html
 
 Templates should all be located in the *<vitrage folder>/templates* folder.
 

doc/source/static-physical-config.rst

@@ -9,13 +9,13 @@ The Static Physical datasource allows users to integrate the physical topology
 into Vitrage. Physical topology includes switches and their connection to
 other switches and physical hosts.
 
-This datasource is static - pre-configured in a file. This is sufficient in 
+This datasource is static - pre-configured in a file. This is sufficient in
 many cases where the physical topology is relatively unchanging.
 
 Configure Access to Static Physical
 -----------------------------------
 
-The following should be set in **/etc/vitrage/vitrage.conf**, under 
+The following should be set in **/etc/vitrage/vitrage.conf**, under
 [static_physical] section:
 
 +------------------+---------------------------------------------------------+----------------------------------+
@@ -32,41 +32,40 @@ The following should be set in **/etc/vitrage/vitrage.conf**, under
 Configure Static Physical Mapping
 ---------------------------------
 
-Physical configuration is made for configuring statically physical entities, 
+Physical configuration is made for configuring statically physical entities,
 and their relationships to other entities in the topology.
 
 Some physical entities, such as switches, can not be retrieved from OpenStack,
 and so are defined here.
 
-There may be more than one configuration file. All files will be read from 
+There may be more than one configuration file. All files will be read from
 */etc/vitrage/static_datasources/*. See previous section on how to configure this
 location.
 
 Format
 ++++++
 
-::
+.. code::
-
-
- entities:
-  - name: <Physical entity name as appears in configuration>
-    id: <Physical entity id as appears in configuration>
-    type: <Physical entity type - see below for details>
-    state: <default resource state>
-    relationships:
-      - type: <Physical entity type it is connected to - see below for details>
-        name: <Name of physical entity as appears in configuration>
-        id: <Id of physical entity as appears in configuration>
-        relation_type: <Relation name>
-      - type: ...
 
+  entities:
+    - name: <Physical entity name as appears in configuration>
+      id: <Physical entity id as appears in configuration>
+      type: <Physical entity type - see below for details>
+      state: <default resource state>
+      relationships:
+        - type: <Physical entity type it is connected to - see below for details>
+          name: <Name of physical entity as appears in configuration>
+          id: <Id of physical entity as appears in configuration>
+          relation_type: <Relation name>
+        - type: ...
   ...
 
 
 Notes:
-- The "type" key must match the name of a type from an existing datasource.
+  - The "type" key must match the name of a type from an existing datasource.
-  Type names appear, for each datasource, in its __init__.py file. For example
+  - Type names appear, for each datasource, in its __init__.py file.
-  see */workspace/dev/vitrage/vitrage/datasources/nova/host/__init__.py*
+  - For example see */workspace/dev/vitrage/vitrage/datasources/nova/host/__init__.py*
+
 
 Example
 +++++++
@@ -74,20 +73,20 @@ Example
 The following will define a switch that is attached to host-1 and is a backup
 of switch-2
 
-::
+.. code::
 
- entities:
+  entities:
-  - type: switch
+    - type: switch
-    name: switch-1
+      name: switch-1
-    id: switch-1 # should be same as name
+      id: switch-1 # should be same as name
-    state: available
+      state: available
-    relationships:
+      relationships:
-      - type: nova.host
+        - type: nova.host
-        name: host-1
+          name: host-1
-        id: host-1 # should be same as name
+          id: host-1 # should be same as name
-        relation_type: attached
+          relation_type: attached
-      - type: switch
+        - type: switch
-        name: switch-2
+          name: switch-2
-        id: switch-2 # should be same as name
+          id: switch-2 # should be same as name
-        relation_type: backup
+          relation_type: backup
 

doc/source/vitrage-first_steps.rst

@@ -11,9 +11,9 @@ Before you start
 
 Installation
 ============
-- `Enable Vitrage in devstack <https://github.com/openstack/vitrage/blob/master/devstack/README.rst/>`_
+- `Enable Vitrage in devstack <https://github.com/openstack/vitrage/blob/master/devstack/README.rst>`_
-- `Enable Vitrage in horizon <https://github.com/openstack/vitrage-dashboard/blob/master/README.rst/>`_
+- `Enable Vitrage in horizon <https://github.com/openstack/vitrage-dashboard/blob/master/README.rst>`_
-- run ./stack.sh
+- run ``./stack.sh``
 
 
 Nagios Installation & Configuration
@@ -27,8 +27,8 @@ as the trigger for deduced alarms, states and RCA templates in Vitrage.
 
 .. _Nagios: https://www.nagios.org/
 
-- `Install Nagios on your devstack <https://github.com/openstack/vitrage/blob/master/doc/source/nagios-devstack-installation.rst/>`_
+- `Install Nagios on your devstack <http://docs.openstack.org/developer/vitrage/nagios-devstack-installation.html>`_
-- `Configure Nagios datasource <https://github.com/openstack/vitrage/blob/master/doc/source/nagios-config.rst>`_
+- `Configure Nagios datasource <http://docs.openstack.org/developer/vitrage/nagios-config.html>`_
 
 
 Vitrage in action
@@ -37,7 +37,7 @@ Vitrage in action
 In order to see Vitrage in action, you should place your templates under
 */etc/vitrage/templates*. See template_ example.
 
-.. _template: https://github.com/openstack/vitrage/blob/master/doc/source/host_high_memory_consumption.yaml
+.. _template: host_high_memory_consumption.yaml
 
 In the example shown here, we will cause Nagios to report high memory usage on
 the devstack host. As a result and as defined in our sample template, Vitrage
@@ -114,12 +114,12 @@ differently, for each data-source you can define it's own mapping to the
 *normalized* states/severities supported in Vitrage. This will impact UI and
 templates behavior that depends on these fields.
 
-- `Resource state configuration <https://github.com/openstack/vitrage/blob/master/doc/source/resource-state-config.rst/>`_
+- `Resource state configuration <http://docs.openstack.org/developer/vitrage/resource-state-config.html>`_
-- `Alarm severity configuration <https://github.com/openstack/vitrage/blob/master/doc/source/alarm-state-config.rst/>`_
+- `Alarm severity configuration <http://docs.openstack.org/developer/vitrage/alarm-severity-config.html>`_
 
 Writing your own templates
 --------------------------
 For more information regarding Vitrage templates, their format and how to add
 them, see here_.
 
-.. _here: https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-template-format.rst
+.. _here: http://docs.openstack.org/developer/vitrage/vitrage-template-format.html

doc/source/zabbix_vitrage.rst

@@ -7,9 +7,9 @@ Consolidate Zabbix alerts from across multiple sites into a single "at-a-glance"
 Installation
 ------------
 
-**Note:** Don't try to use zabbix with docker image to test, because `zabbix_vitrage.py` require some openstack libraries (`oslo.messaging` and `oslo.config`).
+**Note:** Don't try to use zabbix with docker image to test, because ``zabbix_vitrage.py`` requires some openstack libraries (``oslo.messaging`` and ``oslo.config``).
 
-Copy the `zabbix_vitrage.py` script into the Zabbix servers' `AlertScriptsPath` directory which is by default `/usr/lib/zabbix/alertscripts` and make it executable:
+Copy the ``zabbix_vitrage.py`` script into the Zabbix servers' ``AlertScriptsPath`` directory which is by default ``/usr/lib/zabbix/alertscripts`` and make it executable:
 
 .. code-block:: bash
 
@@ -17,7 +17,7 @@ Copy the `zabbix_vitrage.py` script into the Zabbix servers' `AlertScriptsPath`
     $ cp zabbix_vitrage.py /usr/lib/zabbix/alertscripts/
     $ chmod 755 /usr/lib/zabbix/alertscripts/zabbix_vitrage.py
 
-Install `oslo.messaging` and `oslo.config` to zabbix host (may require root):
+Install ``oslo.messaging`` and ``oslo.config`` to zabbix host (may require root):
 
 .. code:: bash
 
@@ -30,35 +30,35 @@ To forward zabbix events to Vitrage a new media script needs to be created and a
 
 1. Create a new media type [Admininstration > Media Types > Create Media Type]
 
-    | Name: Vitrage Notifications
+    | **Name:** Vitrage Notifications
-    | Type: Script
+    | **Type:** Script
-    | Script name: zabbix_vitrage.py
+    | **Script name:** zabbix_vitrage.py
-    | Script parameters:
+    | **Script parameters**:
-    |    1st line: {ALERT.SENDTO}
+    |   **1st line:** {ALERT.SENDTO}
-    |    2nd line: {ALERT.SUBJECT}
+    |   **2nd line:** {ALERT.SUBJECT}
-    |    3rd line: {ALERT.MESSAGE}
+    |   **3rd line:** {ALERT.MESSAGE}
 
 
 2. Modify the Media for the Admin user [Administration > Users]
 
-    | Type: vitrage Notifications
+    | **Type:** Vitrage Notifications
-    | Send to: rabbit://rabbit_user:rabbit_pass@127.0.0.1:5672/   <--- Vitrage message bus url
+    | **Send to:** ``rabbit://rabbit_user:rabbit_pass@127.0.0.1:5672/``   <--- Vitrage message bus url
-    | When active: 1-7,00:00-24:00
+    | **When active:** 1-7,00:00-24:00
-    | Use if severity: tick all options
+    | **Use if severity:** tick all options
-    | Status: Enabled
+    | **Status:** Enabled
 
-    **Note:** Default rabbit_user/rabbit_pass for devstack rabbitmq is `stackrabbit/secret`
+    **Note:** Default ``rabbit_user/rabbit_pass`` for devstack rabbitmq is ``stackrabbit/secret``
 
 3. Configure Action [Configuration > Actions > Create Action > Action]
 
-    | Name: Forward to Vitrage
+    | **Name:** Forward to Vitrage
-    | Default Subject: {TRIGGER.STATUS}
+    | **Default Subject:** {TRIGGER.STATUS}
 
-    | Add an operation:
+    | **Add an operation:**
-    |   Send to Users: Admin
+    |   **Send to Users:** Admin
-    |   Send only to: Vitrage Notifications
+    |   **Send only to:** Vitrage Notifications
 
-    | Default Message:
+    | **Default Message:**
     |   host={HOST.NAME1}
     |   hostid={HOST.ID1}
     |   hostip={HOST.IP1}
@@ -70,35 +70,35 @@ To forward zabbix events to Vitrage a new media script needs to be created and a
     |   priority={TRIGGER.NSEVERITY}
     |   lastchange={EVENT.DATE} {EVENT.TIME}
 
-    | To send events add under the Conditions tab:
+    | **To send events add under the Conditions tab:**
     |   (A) Maintenance status not in `maintenance`
 
 For a full list of trigger macros see https://www.zabbix.com/documentation/3.0/manual/appendix/macros/supported_by_location
 
-To test zabbix events and vitrage alarms, please see zabbix trgger documentation: https://www.zabbix.com/documentation/3.2/manual/config/triggers/trigger
+To test zabbix events and vitrage alarms, please see zabbix trigger documentation: https://www.zabbix.com/documentation/3.2/manual/config/triggers/trigger
 
 
 Vitrage configuration
 ---------------------
 
-1. Add zabbix to list of datasources in /etc/vitrage/vitrage.conf
+1. Add zabbix to list of datasources in ``/etc/vitrage/vitrage.conf``
 
 .. code::
 
     [datasources]
     types = zabbix,nova.host,nova.instance,nova.zone,static_physical,aodh,cinder.volume,neutron.network,neutron.port,heat.stack
 
-2. Add following section to /etc/vitrage/vitrage.conf
+2. Add following section to ``/etc/vitrage/vitrage.conf``
 
 .. code::
 
     [zabbix]
-    url = http://135.248.18.30  # URL to zabbix
+    url = http://<ip>/zabbix  # URL to zabbix
     password = zabbix
     user = admin
     config_file = /etc/vitrage/zabbix_conf.yaml
 
-2. Create /etc/vitrage/zabbix_conf.yaml with this content
+2. Create ``/etc/vitrage/zabbix_conf.yaml`` with this content
 
 .. code ::