remove install section from contributor guide

this is all irrelevant or duplicated:
- dbreco.rst
  - duplicates supported databases in admin-guide
  - ceilometer to gnocchi section is old and deck doesn't really
    reflect current gnocchi. also, all ocata+ docs install
    gnocchi by default.
- custom.rst
  - duplicates telemetry-data-pipelines in admin-guide
  - dups best practices in admin-guide with shuffle option
- upgrade.rst
  - upgrade is just stop, upgrade, restart for each service
  - nothing is unique except notification agent with partitioning[1]
    and existing stuff doesn't address it.

[1] https://bugs.launchpad.net/ceilometer/+bug/1729446

Change-Id: I2de2e7ba8789d896b19320c798150d0c4c6efe0d
(cherry picked from commit 96f346abe8138742a0f68a375e15c8321f29e3bb)

5 files changed, 0 insertions, 352 deletions

diff --git a/doc/source/contributor/index.rst b/doc/source/contributor/index.rst
index 80671e94..ccb34140 100644
--- a/doc/source/contributor/index.rst
+++ b/doc/source/contributor/index.rst
@@ -28,7 +28,6 @@ Developer reference
    architecture
    measurements
    events
-   install/index
    configuration
    plugins
    new_resource_types
diff --git a/doc/source/contributor/install/custom.rst b/doc/source/contributor/install/custom.rst
deleted file mode 100644
index 4b534107..00000000
--- a/doc/source/contributor/install/custom.rst
+++ /dev/null
@@ -1,153 +0,0 @@
-..
-      Licensed under the Apache License, Version 2.0 (the "License"); you may
-      not use this file except in compliance with the License. You may obtain
-      a copy of the License at
-
-          http://www.apache.org/licenses/LICENSE-2.0
-
-      Unless required by applicable law or agreed to in writing, software
-      distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
-      WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
-      License for the specific language governing permissions and limitations
-      under the License.
-
-.. _customizing_deployment:
-
-===================================
- Customizing Ceilometer Deployment
-===================================
-
-Notifications queues
-====================
-
-.. index::
-   double: customizing deployment; notifications queues; multiple topics
-
-By default, Ceilometer consumes notifications on the messaging bus sent to
-**topics** by using a queue/pool name that is identical to the
-topic name. You shouldn't have different applications consuming messages from
-this queue. If you want to also consume the topic notifications with a system
-other than Ceilometer, you should configure a separate queue that listens for
-the same messages.
-
-Ceilometer allows multiple topics to be configured so that the polling agent can
-send the same messages of notifications to other queues. Notification agents
-also use **topics** to configure which queue to listen for. If
-you use multiple topics, you should configure notification agent and polling
-agent separately, otherwise Ceilometer collects duplicate samples.
-
-By default, the ceilometer.conf file is as follows::
-
-   [oslo_messaging_notifications]
-   topics = notifications
-
-To use multiple topics, you should give ceilometer-agent-notification and
-ceilometer-polling services different ceilometer.conf files. The Ceilometer
-configuration file ceilometer.conf is normally locate in the /etc/ceilometer
-directory. Make changes according to your requirements which may look like
-the following::
-
-For notification agent using ceilometer-notification.conf, settings like::
-
-   [oslo_messaging_notifications]
-   topics = notifications,xxx
-
-For polling agent using ceilometer-polling.conf, settings like::
-
-   [oslo_messaging_notifications]
-   topics = notifications,foo
-
-.. note::
-
-   notification_topics in ceilometer-notification.conf should only have one same
-   topic in ceilometer-polling.conf
-
-Doing this, it's easy to listen/receive data from multiple internal and external services.
-
-..  _publisher-configuration:
-
-Using multiple publishers
-=========================
-
-.. index::
-   double: customizing deployment; multiple publishers
-
-Ceilometer allows multiple publishers to be configured in pipeline so that
-data can be easily sent to multiple internal and external systems. Ceilometer
-allows to set two types of pipelines. One is ``pipeline.yaml`` which is for
-meters, another is ``event_pipeline.yaml`` which is for events.
-
-By default, Ceilometer only saves event and meter data into Gnocchi_. If you
-want Ceilometer to send data to other systems, instead of or in addition to
-the default storage services, multiple publishers can be enabled by modifying
-the Ceilometer pipeline.
-
-Ceilometer ships multiple publishers currently. They are ``database``,
-``notifier``, ``file``, ``http`` and ``gnocchi`` publishers.
-
-.. _Gnocchi: http://gnocchi.xyz
-
-To configure one or multiple publishers for Ceilometer, find the Ceilometer
-configuration file ``pipeline.yaml`` and/or ``event_pipeline.yaml`` which is
-normally located at /etc/ceilometer directory and make changes accordingly.
-Your configuration file can be in a different directory.
-
-To use multiple publishers, add multiple publisher lines in ``pipeline.yaml`` and/or
-``event_pipeline.yaml`` file like the following::
-
-   ---
-   sources:
-      - name: source_name
-         events:
-            - "*"
-         sinks:
-            - sink_name
-   sinks:
-      - name: sink_name
-         transformers:
-         publishers:
-            - database://
-            - gnocchi://
-            - file://
-
-For the Gnocchi publisher, the following configuration settings should be added
-into /etc/ceilometer/ceilometer.conf::
-
-    [dispatcher_gnocchi]
-    archive_policy = low
-
-The value specified for ``archive_policy`` should correspond to the name of an
-``archive_policy`` configured within Gnocchi.
-
-For the Gnocchi publisher backed by Swift storage, the following additional
-configuration settings should be added::
-
-    [dispatcher_gnocchi]
-    filter_project = gnocchi_swift
-    filter_service_activity = True
-
-Custom pipeline
-===============
-
-The paths of all pipeline files including ``pipeline.yaml`` and ``event_pipeline.yaml``
-are located to ceilometer/pipeline/data by default. And it's possible to set the
-path through ``pipeline_cfg_file`` being assigned to another one in ``ceilometer.conf``.
-
-Ceilometer allow users to customize pipeline files. Before that, copy the following
-yaml files::
-
-    $ cp ceilometer/pipeline/data/*.yaml /etc/ceilometer
-
-Then you can add configurations according to the former section.
-
-Efficient polling
-=================
-
-- There is an optional config called ``shuffle_time_before_polling_task``
-  in ceilometer.conf. Enable this by setting an integer greater than zero to
-  shuffle polling time for agents. This will add some random jitter to the time
-  of sending requests to Nova or other components to avoid large number of
-  requests in a short time period.
-- There is an option to stream samples to minimise latency (at the
-  expense of load) by setting ``batch_polled_samples`` to ``False`` in
-  ``ceilometer.conf``.
diff --git a/doc/source/contributor/install/dbreco.rst b/doc/source/contributor/install/dbreco.rst
deleted file mode 100644
index 1c55a309..00000000
--- a/doc/source/contributor/install/dbreco.rst
+++ /dev/null
@@ -1,57 +0,0 @@
-..
-      Copyright 2013 Nicolas Barcet for eNovance
-
-      Licensed under the Apache License, Version 2.0 (the "License"); you may
-      not use this file except in compliance with the License. You may obtain
-      a copy of the License at
-
-          http://www.apache.org/licenses/LICENSE-2.0
-
-      Unless required by applicable law or agreed to in writing, software
-      distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
-      WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
-      License for the specific language governing permissions and limitations
-      under the License.
-
-.. _choosing_db_backend:
-
-============================
- Choosing a database backend
-============================
-
-Ceilometer is a data collection service. It normalizes data across OpenStack
-and can be configured to persist the normalized data to multiple services.
-Gnocchi_ is designed to store time-series **measurement data**. Panko_ is
-intended to capture **event data**. Lastly, Aodh_ provides **alarming**
-functionality.
-
-Moving from Ceilometer to Gnocchi
-=================================
-
-Gnocchi represents a fundamental change in how data is represented and stored.
-Installation and configuration can be found in :ref:`installing_manually`.
-Differences between APIs can be found here_.
-
-There currently exists no migration tool between the services. To transition
-to Gnocchi, multiple publishers can be enabled in the Collector to capture
-data in both the native Ceilometer database and Gnocchi. This will allow you
-to test Gnocchi and transition to it fully when comfortable. Edit the
-``pipeline.yaml`` and ``event_pipeline.yaml`` to include multiple publishers::
-
-  ---
-  sources:
-      - name: event_source
-        events:
-            - "*"
-        sinks:
-            - event_sink
-  sinks:
-      - name: event_sink
-        publishers:
-            - gnocchi://
-            - database://
-
-.. _Gnocchi: http://gnocchi.xyz
-.. _Aodh: https://docs.openstack.org/aodh/latest/
-.. _Panko: https://docs.openstack.org/panko/latest/
-.. _here: https://www.slideshare.net/GordonChung/ceilometer-to-gnocchi
diff --git a/doc/source/contributor/install/index.rst b/doc/source/contributor/install/index.rst
deleted file mode 100644
index 35e7dbad..00000000
--- a/doc/source/contributor/install/index.rst
+++ /dev/null
@@ -1,27 +0,0 @@
-..
-      Copyright 2013 New Dream Network, LLC (DreamHost)
-
-      Licensed under the Apache License, Version 2.0 (the "License"); you may
-      not use this file except in compliance with the License. You may obtain
-      a copy of the License at
-
-          http://www.apache.org/licenses/LICENSE-2.0
-
-      Unless required by applicable law or agreed to in writing, software
-      distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
-      WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
-      License for the specific language governing permissions and limitations
-      under the License.
-
-.. _install:
-
-=======================
- Installing Ceilometer
-=======================
-
-.. toctree::
-   :maxdepth: 2
-
-   dbreco
-   custom
-   upgrade
diff --git a/doc/source/contributor/install/upgrade.rst b/doc/source/contributor/install/upgrade.rst
deleted file mode 100644
index d196eae7..00000000
--- a/doc/source/contributor/install/upgrade.rst
+++ /dev/null
@@ -1,114 +0,0 @@
-..
-      Licensed under the Apache License, Version 2.0 (the "License"); you may
-      not use this file except in compliance with the License. You may obtain
-      a copy of the License at
-
-          http://www.apache.org/licenses/LICENSE-2.0
-
-      Unless required by applicable law or agreed to in writing, software
-      distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
-      WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
-      License for the specific language governing permissions and limitations
-      under the License.
-
-.. _upgrade:
-
-==========
- Upgrading
-==========
-
-Ceilometer's services support both full upgrades as well as partial
-(rolling) upgrades. The required steps for each process are described below.
-
-
-Full upgrades
-=============
-
-The following describes how to upgrade your entire Ceilometer environment in
-one pass.
-
-.. _full upgrade path:
-
-1. Upgrade the database (if applicable)
-
-   Run ceilometer-upgrade to upgrade the storage backend if using one of
-   Ceilometer's databases (see :ref:`choosing_db_backend`). The database does
-   not need to be taken offline. Ideally this should be done during a period of
-   low activity. Best practices should still be followed (ie. back up your
-   data). If not using a Ceilometer database, you should consult the
-   documentation of that storage beforehand.
-
-2. Upgrade the collector service(s)
-
-   Shutdown all collector services. The new collector, that knows how to
-   interpret the new payload, can then be started. It will disregard any
-   historical attributes and can continue to process older data from the
-   agents. You may restart as many new collectors as required.
-
-3. Upgrade the notification agent(s)
-
-   The notification agent can then be taken offline and upgraded with the
-   same conditions as the collector service.
-
-4. Upgrade the polling agent(s)
-
-   In this path, you'll want to take down agents on all hosts before starting.
-   After starting the first agent, you should verify that data is again being
-   polled. Additional agents can be added to support coordination if enabled.
-
-.. note::
-
-   The API service can be taken offline and upgraded at any point in the
-   process (if applicable).
-
-
-Partial upgrades
-================
-
-The following describes how to upgrade parts of your Ceilometer environment
-gradually. The ultimate goal is to have all services upgraded to the new
-version in time.
-
-1. Upgrade the database (if applicable)
-
-   Upgrading the database here is the same as the `full upgrade path`_.
-
-2. Upgrade the collector service(s)
-
-   The new collector services can be started alongside the old collectors.
-   Collectors old and new will disregard any new or historical attributes.
-
-3. Upgrade the notification agent(s)
-
-   The new notification agent can be started alongside the old agent if no
-   workload_partioning is enabled OR if it has the same pipeline configuration.
-   If the pipeline configuration is changed, the old agents must be loaded with
-   the same pipeline configuration first to ensure the notification agents all
-   work against same pipeline sets.
-
-4. Upgrade the polling agent(s)
-
-   The new polling agent can be started alongside the old agent only if no new
-   pollsters were added. If not, new polling agents must start only in its
-   own partitioning group and poll only the new pollsters. After all old agents
-   are upgraded, the polling agents can be changed to poll both new pollsters
-   AND the old ones.
-
-5. Upgrade the API service(s)
-
-   API management is handled by WSGI so there is only ever one version of API
-   service running
-
-.. note::
-
-   Upgrade ordering does not matter in partial upgrade path. The only
-   requirement is that the database be upgraded first. It is advisable to
-   upgrade following the same ordering as currently described: database,
-   collector, notification agent, polling agent, api.
-
-
-Developer notes
-===============
-
-When updating data models in the database or IPC, we need to adhere to a single
-mantra: 'always add, never delete or modify.'