From 08974ed5602dbe61df6558472f282b224777525f Mon Sep 17 00:00:00 2001 From: gord chung Date: Tue, 17 Oct 2017 18:50:53 +0000 Subject: [PATCH] cleanup collector references we don't have collector anymore. R.I.P. Change-Id: Ie1ea64622f92571373f842668b7573fd45953680 --- doc/source/admin/telemetry-data-collection.rst | 5 ----- doc/source/admin/telemetry-data-pipelines.rst | 5 ----- .../admin/telemetry-system-architecture.rst | 15 ++++----------- doc/source/contributor/architecture.rst | 4 ++-- doc/source/contributor/plugins.rst | 6 +++--- 5 files changed, 9 insertions(+), 26 deletions(-) diff --git a/doc/source/admin/telemetry-data-collection.rst b/doc/source/admin/telemetry-data-collection.rst index 864856770f..42fca44f35 100644 --- a/doc/source/admin/telemetry-data-collection.rst +++ b/doc/source/admin/telemetry-data-collection.rst @@ -48,11 +48,6 @@ such as transformations and publishing. After processing, the data is sent to any supported publisher target such as gnocchi or panko. These services persist the data in configured databases. -.. note:: - - Prior to Ocata, the data was sent via AMQP to the collector service or any - external service. - The different OpenStack services emit several notifications about the various types of events that happen in the system during normal operation. Not all these notifications are consumed by the Telemetry diff --git a/doc/source/admin/telemetry-data-pipelines.rst b/doc/source/admin/telemetry-data-pipelines.rst index 0838e0abd8..7f40458c91 100644 --- a/doc/source/admin/telemetry-data-pipelines.rst +++ b/doc/source/admin/telemetry-data-pipelines.rst @@ -415,11 +415,6 @@ The notifier publisher can be specified in the form of oslo.messaging. Any consumer can then subscribe to the published topic for additional processing. -.. note:: - - Prior to Ocata, the collector would consume this publisher but has since - been deprecated and therefore not required. - The following customization options are available: ``per_meter_topic`` diff --git a/doc/source/admin/telemetry-system-architecture.rst b/doc/source/admin/telemetry-system-architecture.rst index 1c35afda4e..13d182e254 100644 --- a/doc/source/admin/telemetry-system-architecture.rst +++ b/doc/source/admin/telemetry-system-architecture.rst @@ -24,19 +24,12 @@ ceilometer-agent-notification Consumes AMQP messages from other OpenStack services, normalizes messages, and publishes them to configured targets. -ceilometer-collector (deprecated in Ocata) - Consumes AMQP notifications from the agents, then dispatches these - data to the appropriate data store. - .. note:: - 1. The ``ceilometer-polling`` service provides polling support on any - namespace but many distributions continue to provide namespace-scoped - agents: ``ceilometer-agent-central``, ``ceilometer-agent-compute``, - and ``ceilometer-agent-ipmi``. - - 2. The ``ceilometer-collector`` is no longer supported since the Ocata - release. Storage is provided by gnocchi, aodh, and panko services. + The ``ceilometer-polling`` service provides polling support on any + namespace but many distributions continue to provide namespace-scoped + agents: ``ceilometer-agent-central``, ``ceilometer-agent-compute``, + and ``ceilometer-agent-ipmi``. Except for the ``ceilometer-polling`` agents polling the ``compute`` or ``ipmi`` namespaces, all the other services are placed on one or more diff --git a/doc/source/contributor/architecture.rst b/doc/source/contributor/architecture.rst index f4deeda978..5ba18e79a8 100644 --- a/doc/source/contributor/architecture.rst +++ b/doc/source/contributor/architecture.rst @@ -52,9 +52,9 @@ How is data collected? .. figure:: ./1-agents.png :width: 100% :align: center - :alt: Collectors and agents + :alt: agents - This is a representation of how the collectors and agents gather data from + This is a representation of how the agents gather data from multiple sources. The Ceilometer project created 2 methods to collect data: diff --git a/doc/source/contributor/plugins.rst b/doc/source/contributor/plugins.rst index c485fbd884..72608c764a 100644 --- a/doc/source/contributor/plugins.rst +++ b/doc/source/contributor/plugins.rst @@ -32,7 +32,7 @@ compute nodes (where direct hypervisor polling is quite logical). The agent running on each compute node polls for compute resources usage. Each meter collected is tagged with the resource ID (such as an instance) and the owner, including tenant and user IDs. The meters -are then reported to the collector via the message bus. More detailed +are then reported to the notification agent via the message bus. More detailed information follows. The agent running on the cloud central management node polls other types of @@ -48,7 +48,7 @@ Plugins ~~~~~~~ A polling agent can support multiple plugins to retrieve different -information and send them to the collector. As stated above, an agent +information and send them to the notification agent. As stated above, an agent will automatically activate all possible plugins if no additional information about what to poll was passed. Previously we had separated compute and central agents with different namespaces with plugins (pollsters) defined @@ -134,7 +134,7 @@ In the ``InstanceNotifications`` plugin, it listens to three events: Using the ``get_event_type`` method and subsequently the method ``process_notification`` will be invoked each time such events are happening which -generates the appropriate sample objects to be sent to the collector. +generates the appropriate sample objects to be sent to the publisher targets. Adding new plugins ------------------