cleanup collector references

we don't have collector anymore. R.I.P.

Change-Id: Ie1ea64622f92571373f842668b7573fd45953680

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

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``

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

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:

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
 ------------------