Merge "cleanup admin-guide architecture"

doc/source/admin/telemetry-system-architecture.rst

@@ -5,24 +5,15 @@ System architecture
 ===================
 
 The Telemetry service uses an agent-based architecture. Several modules
-combine their responsibilities to collect data, store samples in a
+combine their responsibilities to collect, normalize, and redirect data
-database, or provide an API service for handling incoming requests.
+to be used for use cases such as metering, monitoring, and alerting.
 
-The Telemetry service is built from the following agents and services:
+The Telemetry service is built from the following agents:
 
 ceilometer-polling
     Polls for different kinds of meter data by using the polling
     plug-ins (pollsters) registered in different namespaces. It provides a
-    single polling interface across different namespaces. The ``compute``
+    single polling interface across different namespaces.
-    namespace polls the local hypervisor to acquire performance data of local
-    instances. The ``central`` namespace polls the public RESTful APIs of other
-    OpenStack services such as Compute service and Image service. The ``ipmi``
-    namespace polls the local node with IPMI support, in order to acquire IPMI
-    sensor data and Intel Node Manager datahost-level information.
-
-ceilometer-agent-notification
-    Consumes AMQP messages from other OpenStack services, normalizes messages,
-    and publishes them to configured targets.
 
 .. note::
 
@@ -31,11 +22,15 @@ ceilometer-agent-notification
    agents: ``ceilometer-agent-central``, ``ceilometer-agent-compute``,
    and ``ceilometer-agent-ipmi``.
 
+ceilometer-agent-notification
+    Consumes AMQP messages from other OpenStack services, normalizes messages,
+    and publishes them to configured targets.
+
 Except for the ``ceilometer-polling`` agents polling the ``compute`` or
 ``ipmi`` namespaces, all the other services are placed on one or more
 controller nodes.
 
-The Telemetry architecture highly depends on the AMQP service both for
+The Telemetry architecture depends on the AMQP service both for
 consuming notifications coming from OpenStack services and internal
 communication.
 
@@ -71,8 +66,6 @@ The list of supported base back ends for events:
 
 -  `PostgreSQL <http://www.postgresql.org/>`__
 
--  `HBase <http://hbase.apache.org/>`__
-
 
 .. _telemetry-supported-hypervisors:
 
@@ -85,67 +78,23 @@ compute hosts.
 
 The following is a list of supported hypervisors.
 
--  The following hypervisors are supported via `libvirt <http://libvirt.org/>`__
+-  `Libvirt supported hypervisors <http://libvirt.org/>`__ such as KVM and QEMU
-
+-  `Hyper-V <http://www.microsoft.com/en-us/server-cloud/hyper-v-server/default.aspx>`__
-   *  `Kernel-based Virtual Machine (KVM) <http://www.linux-kvm.org/page/Main_Page>`__
+-  `XEN <http://www.xenproject.org/help/documentation.html>`__
-
+-  `VMware vSphere <https://www.vmware.com/support/vsphere-hypervisor.html>`__
-   *  `Quick Emulator (QEMU) <http://wiki.qemu.org/Main_Page>`__
-
-   *  `Linux Containers (LXC) <https://linuxcontainers.org/>`__
-
-   *  `User-mode Linux (UML) <http://user-mode-linux.sourceforge.net/>`__
 
 .. note::
 
-      For details about hypervisor support in libvirt please check the
+   For details about hypervisor support in libvirt please see the
    `Libvirt API support matrix <http://libvirt.org/hvsupport.html>`__.
 
--  `Hyper-V <http://www.microsoft.com/en-us/server-cloud/hyper-v-server/default.aspx>`__
-
--  `XEN <http://www.xenproject.org/help/documentation.html>`__
-
--  `VMware vSphere <https://www.vmware.com/support/vsphere-hypervisor.html>`__
-
 
 Supported networking services
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Telemetry is able to retrieve information from OpenStack Networking and
+Telemetry is able to retrieve information from external networking services:
-external networking services:
-
--  OpenStack Networking:
-
-   -  Basic network meters
-
-   -  Firewall-as-a-Service (FWaaS) meters
-
-   -  Load-Balancer-as-a-Service (LBaaS) meters
-
-   -  VPN-as-a-Service (VPNaaS) meters
 
 -  SDN controller meters:
 
    -  `OpenDaylight <https://www.opendaylight.org/>`__
-
    -  `OpenContrail <http://www.opencontrail.org/>`__
-
-
-.. _telemetry-users-roles-projects:
-
-Users, roles, and projects
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-This service of OpenStack uses OpenStack Identity for authenticating and
-authorizing users. The required configuration options are listed in the
-`Telemetry section
-<https://docs.openstack.org/ceilometer/latest/configuration/index.html>`__ in the
-OpenStack Configuration Reference. Alternatively, gnocchi can be configured
-without authentication to minimize overhead.
-
-The system uses two roles:``admin`` and ``non-admin``. The authorization
-happens before processing each API request. The amount of returned data
-depends on the role the requestor owns.
-
-The creation of alarm definitions also highly depends on the role of the
-user, who initiated the action. Further details about :ref:`telemetry-alarms`
-handling can be found in this guide.