Browse Source

Redis Plugin Doc final review for MOS 8 & 7

Change-Id: I422b1fd4c6f6c763c0fb622ce8dd0afba00a4429
Patrick Petit 2 years ago
parent
commit
5e6601c98f

+ 5
- 5
doc/source/conf.py View File

@@ -4,10 +4,10 @@ extensions = []
4 4
 templates_path = ['_templates']
5 5
 source_suffix = '.rst'
6 6
 master_doc = 'index'
7
-project = u'The Redis Plugin for Ceilometer documentation'
7
+project = u'The Ceilometer Redis Plugin'
8 8
 copyright = u'2016, Mirantis Inc.'
9 9
 version = '0.1'
10
-release = '0.1.0'
10
+release = '0.1.2'
11 11
 exclude_patterns = [
12 12
 ]
13 13
 pygments_style = 'sphinx'
@@ -16,15 +16,15 @@ htmlhelp_basename = 'RedisPlugindoc'
16 16
 latex_elements = {
17 17
 }
18 18
 latex_documents = [
19
-  ('index', 'RedisPlugindoc.tex', u'The Redis Plugin for Ceilometer documentation',
19
+  ('index', 'RedisPlugindoc.tex', u'The Ceilometer Redis Plugin',
20 20
    u'Mirantis Inc.', 'manual'),
21 21
 ]
22 22
 man_pages = [
23
-    ('index', 'redisplugin', u'The Redis Plugin for Ceilometer documentation',
23
+    ('index', 'redisplugin', u'The Ceilometer Redis Plugin',
24 24
      [u'Mirantis Inc.'], 1)
25 25
 ]
26 26
 texinfo_documents = [
27
-  ('index', 'RedisPlugin', u'The Redis Plugin for Ceilometer documentation',
27
+  ('index', 'RedisPlugin', u'The Ceilometer Redis Plugin',
28 28
    u'Mirantis Inc.', 'RedisPlugin', 'One line description of project.',
29 29
    'Miscellaneous'),
30 30
 ]

+ 100
- 67
doc/source/description.rst View File

@@ -1,45 +1,100 @@
1
-Ceilometer Redis plugin
2
-=======================
3
-
4
-Ceilometer Redis Plugin aims to install Redis to MOS environment and provide a coordination mechanism for
5
-`Ceilometer agents <https://ceilometer.readthedocs.org/en/latest/architecture.html>`_ and Alarm Evaluator
6
-through the `tooz library <http://docs.openstack.org/developer/tooz/>`_ with a `Redis backend <http://redis.io>`_
7
-The plugin supports coordination for the following Ceilometer services: central agent and alarm-evaluator.
8
-Each of these services are running on every controller after the plugin is installed. All of them are joined
9
-into the corresponding coordination group (one coordination group per each service). It differs from the default
10
-configuration when there should be only one central agent and alarm-evaluator per cloud. The plugin also configures
11
-redis-server under pacemaker to monitor its process. The plugin configures `redis-sentinel <http://redis.io/topics/sentinel>`_
12
-to monitor the state of the redis cluster, to elect new master during failovers, to forward ceilometer services to new
13
-elected redis master, to organize sync between redis nodes.
14
-
15
-
16
-Central agent
17
--------------
18
-Ceilometer Central agent is responsible for polling all OpenStack resources except Nova's (Nova resources,
19
-i.e. vms, are polled by a Compute agent). Without coordination enabled, only one Central agent should be running
20
-per cloud. The reason is that all the central agents have the same set of OpenStack resources to poll every
21
-configurable time interval. If coordination is not enabled, each OpenStack resource will be polled as many times
22
-as many instances of Central agents are running in a cloud.
23
-Thus, coordination provides a disjoint set of OpenStack resources to poll for every Central agent running on the
24
-cloud to avoid polling one resource several times.
25
-
26
-Alarm evaluator
27
----------------
28
-Ceilometer alarm evaluator service is responsible for Ceilometer alarm evaluation.
29
-By default, in MOS there is only one alarm evaluator per cloud. The reason is the same as for a central agent.
30
-If there are several alarm evaluators and no coordination enabled, all of them will evaluate the same set of alarms
31
-every configurable time interval. The alarm sets for evaluators should be disjoint. So, coordination is responsible
32
-for providing the set of alarms to evaluate to each alarm-evaluator in the cloud.
33
-
1
+Overview
2
+========
3
+
4
+The *Ceilometer Redis Plugin* installs `Redis <http://redis.io>`_ and
5
+the `Tooz library <http://docs.openstack.org/developer/tooz/>`_, in a
6
+Mirantis OpenStack (MOS) environment deployed by Fuel.
7
+Both Redis and the Tooz library should be installed on all the controller
8
+nodes of the environment.
9
+
10
+The *Ceilometer Redis Plugin* is used to provide coordination mechanisms to
11
+enable the horizontal scaling of the Ceilometer services. Using the plugin,
12
+the Ceilometer services are joined into a so-called **coordination group**,
13
+which allows for resources and alarms sharding.
14
+There is one coordination group per service type.
15
+
16
+Please refer to the `Telemetry architecture
17
+<http://docs.openstack.org/admin-guide/telemetry-system-architecture.html>`_
18
+documentation for more information about the Ceilometer services.
19
+
20
+In MOS 7.0 and MOS 8.0, the *Ceilometer Redis Plugin* enables coordination
21
+for both:
22
+
23
+  * The **ceilometer-agent-central service**.
24
+
25
+    The ceilometer-agent-central service is responsible for polling all the OpenStack resources,
26
+    excepted those of Nova, like the VM instances, that are polled by the **ceilometer-agent-compute**.
27
+    Without coordination, there can be only one ceilometer-agent-central running at a time.
28
+    This is because, by default, the ceilometer-agent-central works with an entire set of resources.
29
+    As such, running multiple ceilometer-agent-central without coordination would poll the entire
30
+    set of resources as many times as the number of agents running on the controller nodes every
31
+    polling interval. This is obviously not a proper way to scale out the ceilometer-agent-central.
32
+    To cope with this problem, the coordination mechanism provided
33
+    by the *Ceilometer Redis Plugin* allows distributing the polling workload
34
+    across multiple instances of the ceilometer-agent-central using disjoint sets
35
+    of resources.
36
+
37
+  * The **ceilometer-alarm-evaluator service**.
38
+
39
+    The **ceilometer-alarm-evaluator** service is responsible for evaluating the Ceilometer alarms.
40
+    By default, there is only one ceilometer-alarm-evaluator running per environment.
41
+    Without coordination, there can be only one ceilometer-alarm-evaluator running at a time.
42
+    This is because, as for the ceilometer-agent-central, the ceilometer-alarm-evaluator works
43
+    with an entire set of alarms. Running multiple ceilometer-alarm-evaluator
44
+    without coordination would evaluate all the alarms as many times as the number of evaluators
45
+    running on the controller nodes every evaluation interval. To cope with this problem,
46
+    the coordination mechanism provided by the *Ceilometer Redis Plugin* allows distributing
47
+    the alarms evaluation workload across multiple instances of the ceilometer-alarm-evaluator
48
+    using disjoint sets of alarms.
49
+
50
+Please note that with MOS 8.0, the *Ceilometer Redis Plugin* doesn't provide support
51
+(out-of-the-box) for the coordination of the **ceilometer-agent-notification** service because
52
+it is not needed for the most common samples transformations.
53
+
54
+.. note:: Before Liberty, the transformation of the samples was handled by the
55
+   **ceilometer-agent-compute** and the **ceilometer-agent-central** services.
56
+   In Liberty, the transformation of the samples was moved
57
+   to the **ceilometer-agent-notification** service, but after thorough performance analysis
58
+   of Ceilometer at scale, we discovered that this change has a bad impact on performance.
59
+   In MOS 8.0, the transformations for the following list of measurements were moved back
60
+   to the ceilometer-agent-compute service.
61
+
62
+   * cpu_util
63
+   * disk.read.requests.rate
64
+   * disk.write.requests.rate
65
+   * disk.read.bytes.rate
66
+   * disk.write.bytes.rate
67
+   * disk.device.read.requests.rate
68
+   * disk.device.read.bytes.rate
69
+   * disk.device.write.bytes.rate
70
+   * network.incoming.bytes.rate
71
+   * network.outgoing.bytes.rate
72
+   * network.incoming.packets.rate
73
+   * network.outgoing.packets.rate
74
+
75
+   As a result, in MOS 8.0, there is no need to run the ceilometer-agent-notification
76
+   in coordination mode unless you need to maintain the transformation of custom samples that
77
+   are not listed above. In this case, it is possible to enable coordination for the
78
+   ceilometer-agent-notification service manually event though, it is not recommended
79
+   for performance reasons.
80
+
81
+In addition to the above, the *Ceilometer Redis Plugin* configures *Pacemaker*
82
+and `redis-sentinel <http://redis.io/topics/sentinel>`_
83
+to enable **high availability** of the Redis cluster. Redis clustering includes:
84
+
85
+   * Monitoring the state of the **redis-server** processes
86
+   * Elect a new redis-server master during a failover
87
+   * Connect Ceilometer to the elected redis-server
88
+   * Organize the synchronization between Redis nodes
34 89
 
35 90
 Requirements
36 91
 ------------
37 92
 
38 93
 ======================= ================
39
-Requirement             Version/Comment
94
+Requirements            Version/Comment
40 95
 ======================= ================
41
-Fuel                    7.0, 8.0
42
-tooz                    <0.14.0,>=0.13.1
96
+MOS                     7.0, 8.0
97
+Tooz                    <0.14.0,>=0.13.1
43 98
 ======================= ================
44 99
 
45 100
 .. _limitations:
@@ -47,35 +102,13 @@ tooz                    <0.14.0,>=0.13.1
47 102
 Limitations
48 103
 -----------
49 104
 
50
-* The plugin works correctly only on clouds with odd numbers of controllers.
51
-  This requirement is mandatory because Redis needs an odd number of nodes to
52
-  choose the master successfully.
53
-
54
-* Before Liberty, there was no need to coordinate Ceilometer notification agents. Starting from Liberty, samples
55
-  transformations started to be handled not by compute/central agents as it was before, but by a notification agent.
56
-  Some of Ceilometer transformers have a local cache where they store the data from the previously processed samples.
57
-  For example, "cpu_util" metric are obtained from two consecutive Samples with "cpu" metric: one is subtracted from
58
-  another and divided by an amount of cpu (this information is stored in Sample's metadata).
59
-  Thus, it should be guaranteed that all the Samples which should be transformed by one transformer, will go to the
60
-  same notification agent. If some of the samples go to another, the cache cannot be shared and some data will be lost.
61
-
62
-  To handle this process properly, IPC queues was introduced  - inter process communication queues in message bus
63
-  (RabbitMQ). With coordination enabled, each notification agent has two set of listeners: for main queues and for IPC
64
-  queues. All notification agents listen to _all_ the main queues (where we have all messages from OpenStack services
65
-  and polling-based messages from central/compute agents) and re-publish messages to _all_ IPC queues. Coordination
66
-  starts to work at this point: every notification agent in the cloud has it's own set of IPC queues to listen to. Thus,
67
-  we can be sure that local cache on each notification agent contains all the previous data required for transformation.
68
-
69
-  After some investigations, some performance issues were found with IPC approach. That's why in In MOS 8.0 all basic
70
-  transformations (cpu_util, disk.read.requests.rate, disk.write.requests.rate, disk.read.bytes.rate, disk.write.bytes.rate,
71
-  disk.device.read.requests.rate, disk.device.read.bytes.rate, disk.device.write.bytes.rate, network.incoming.bytes.rate,
72
-  network.outgoing.bytes.rate, network.incoming.packets.rate, network.outgoing.packets.rate) were moved back to compute
73
-  nodes, i.e. for the basic set of transformations there is no need to run notification agent in coordination mode.
74
-  That's the reason why the plugin does't support coordination for notification agents, although it is possible to configure
75
-  notification agents to run in coordination mode manually. Anyway, it is not recommended.
76
-
77
-  If you have any custom transformers, you need to be sure that they are cache-less, i.e. are based only on
78
-  ``unit_conversion`` transformer or the ``arithmetic`` transformer. If it's not the case, you may consider the following
79
-  options: run only one notification agent in the cloud or install this plugin and do all configuration manually.
80
-
105
+* The *Ceilometer Redis Plugin* requires to install on an odd number of controller
106
+  nodes to work properly. This is because, Redis clustering requires an odd number of nodes
107
+  to avoid the split brain effect when electing a master.
81 108
 
109
+* If you have any custom transformers you need to ensure that they are cache-less.
110
+  If transformation is cache-less, then there is no need to enable the coordination.
111
+  That is, based only on the ``unit_conversion`` transformer or the ``arithmetic`` transformers.
112
+  Otherwise, you will have to consider running only one instance of the ceilometer-agent-notification
113
+  service in your MOS environment or install the *Ceilometer Redis Plugin* and do all the
114
+  configuration manually.

+ 69
- 75
doc/source/guide.rst View File

@@ -1,115 +1,109 @@
1 1
 User Guide
2 2
 ==========
3 3
 
4
-Once the Ceilometer Redis plugin plugin has been installed  (following :ref:`Installation Guide`), you can
5
-create *OpenStack* environments with Ceilometer whose Central agents and Alarm evaluator
6
-work in workload_partitioned mode.
4
+Once the *Ceilometer Redis Plugin* is installed following the instructions of
5
+the :ref:`Installation Guide`, you can create a Mirantis OpenStack (MOS) environment
6
+with Ceilometer whose **ceilometer-agent-central** and **ceilometer-alarm-evaluator**
7
+services will work in **workload partitioned** mode.
8
+This plugin was created to enable the scale-out of these Ceilometer services.
9
+It is useless and **shouldn't be used if Ceilometer is not installed**.
7 10
 
8
-Ceilometer installation
9
------------------------
11
+Plugin Configuration
12
+--------------------
10 13
 
11
-This plugin was created to provide partitioning for Ceilometer services. So its
12
-usage is senseless without Ceilometer installed.
13
-So, you will need to `create a new OpenStack environment <https://docs.mirantis.com/openstack/fuel/fuel-8.0/user-guide.html#create-a-new-openstack-environment>`_
14
-with `Ceilometer <https://docs.mirantis.com/openstack/fuel/fuel-8.0/user-guide.html#related-projects>`_ using the Fuel UI Wizard.
14
+To use the *Ceilometer Redis Plugin*, you need to `create a new MOS environment
15
+<http://docs.openstack.org/developer/fuel-docs/userdocs/fuel-user-guide/create-environment.html>`_
16
+with the `Telemetry service
17
+<http://docs.openstack.org/admin-guide/telemetry.html>`_
18
+(a.k.a Ceilometer) enabled and follow these steps using the *Fuel UI Wizard*.
15 19
 
20
+1. Make sure that the plugin is properly installed on the Fuel Master node.
16 21
 
17
-Plugin configuration in MOS 8.0
18
--------------------------------
19
-
20
-#. First of all, make sure that plugin was successfully installed.
21 22
    Go to the *Plugins* tab. You should see the following:
22 23
 
23
-   .. image:: images/redis-plugin-on8.0.png
24
-    :width: 100%
25
-
26
-#. The next step is enable the plugin. Go to *Environments* tab and
27
-   select the *Redis plugin for Ceilometer* checkbox:
24
+   On Mos 8.0
28 25
 
29
-   .. image:: images/redis-plugin-8.0.png
26
+   .. image:: images/redis-plugin.png
30 27
     :width: 100%
31 28
 
32
-#. When adding nodes to environment and assigning roles to them <https://docs.mirantis.com/openstack/fuel/fuel-8.0/operations.html#adding-redeploying-and-replacing-nodes>`_, please consider using odd number of controllers as mentioned in :ref:`Limitations`.
33
-
34
-#. Finish
35
-   `environment configuration <https://docs.mirantis.com/openstack/fuel/fuel-8.0/mos-planning-guide.html#fuel-reference-architecture-overview>`_
29
+   On Mos 7.0
36 30
 
37
-#. Run `network verification check <https://docs.mirantis.com/openstack/fuel/fuel-8.0/operations.html#network-issues>`_.
31
+   .. image:: images/redis-plugin-on8-0.png
32
+    :width: 100%
38 33
 
39
-#. Press "Deploy button" to once you are done with environment configuration.
34
+2. Enable the plugin.
40 35
 
41
-Plugin configuration in MOS 7.0
42
--------------------------------
36
+   Go to the *Environments* tab and select the *Redis plugin for Ceilometer* checkbox:
43 37
 
44
-#. First of all, make sure that plugin was successfully installed.
45
-   Go to the *Plugins* tab. You should see the following:
38
+   On Mos 8.0
46 39
 
47
-   .. image:: images/redis-plugin.png
40
+   .. image:: images/redis-plugin-8-0.png
48 41
     :width: 100%
49 42
 
50
-#. The next step is enable the plugin. Go to *Environments* tab and
51
-   select the *Redis plugin for Ceilometer* checkbox:
43
+   On Mos 7.0
52 44
 
53 45
    .. image:: images/redis-plugin-on.png
54 46
     :width: 100%
55 47
 
56
-#. When
57
-   `adding nodes to environment and assigning roles to them in MOS 7.0 <https://docs.mirantis.com/openstack/fuel/fuel-7.0/user-guide.html#add-nodes-ug>`_, please consider using odd number of controllers as mentioned in :ref:`Limitations`.
58
-
59
-#. Finish
60
-   `environment configuration for MOS 7.0 <https://docs.mirantis.com/openstack/fuel/fuel-7.0/user-guide.html#configure-your-environment>`_
48
+3.  Add nodes to your environment to which you will assign the **controller role**.
61 49
 
62
-#. Run `network verification check for MOS 7.0 <https://docs.mirantis.com/openstack/fuel/fuel-7.0/user-guide.html#verify-networks>`_.
50
+   .. note:: When `adding nodes
51
+      <http://docs.openstack.org/developer/fuel-docs/userdocs/fuel-user-guide/configure-environment/add-nodes.html>`_
52
+      to the environment and `assign or change a role
53
+      <http://docs.openstack.org/developer/fuel-docs/userdocs/fuel-user-guide/configure-environment/change-roles.html>`_,
54
+      do not forget to use an odd number of controllers as mentioned in :ref:`Limitations` section.
63 55
 
64
-#. Press `Deploy button <https://docs.mirantis.com/openstack/fuel/fuel-7.0/user-guide.html#deploy-changes>`_ to once you are done with environment configuration.
56
+4. `Verify your network configuration
57
+   <http://docs.openstack.org/developer/fuel-docs/userdocs/fuel-user-guide/configure-environment/verify-networks.html>`_.
65 58
 
59
+5. `Deploy your changes
60
+   <http://docs.openstack.org/developer/fuel-docs/userdocs/fuel-user-guide/deploy-environment.html>`_
61
+   once you are done with the configuration of your environment.
66 62
 
63
+Plugin Verification
64
+-------------------
67 65
 
68
-How to check that plugin works
69
-------------------------------
70
-#. Check that ceilometer-agent-central and ceilometer-alarm-evaluator services are running
71
-   on each controller. Run ``pcs resource`` and you should see the following in the output::
66
+#. Check that the ceilometer-agent-central and ceilometer-alarm-evaluator services are running
67
+   on each controller.
72 68
 
73
-          Clone Set: clone_p_ceilometer-agent-central [p_ceilometer-agent-central]
74
-            Started: [ node-21.domain.tld node-27.domain.tld node-33.domain.tld ]
69
+   Run ``pcs resource``. You should see the following in the output::
75 70
 
76
-          Clone Set: clone_p_ceilometer-alarm-evaluator [p_ceilometer-alarm-evaluator]
77
-            Started: [ node-21.domain.tld node-27.domain.tld node-33.domain.tld ]
71
+     Clone Set: clone_p_ceilometer-agent-central [p_ceilometer-agent-central]
72
+       Started: [ node-21.domain.tld node-27.domain.tld node-33.domain.tld ]
78 73
 
79
-   ``Started`` list should contain all controllers.
74
+     Clone Set: clone_p_ceilometer-alarm-evaluator [p_ceilometer-alarm-evaluator]
75
+       Started: [ node-21.domain.tld node-27.domain.tld node-33.domain.tld ]
80 76
 
81
-#. For the central agent: check that samples are not duplicated. For this purpose you may choose
82
-   any metric collected by central agent. All these metrics may be found here
83
-   `Measurements <http://docs.openstack.org/admin-guide-cloud/telemetry-measurements.html>`_ .
84
-   You may choose any section *except* OpenStack Compute and then select metric with 'Pollster' Origin.
85
-   For example, let's choose storage.objects.
77
+   The *Started* list should contain all controllers.
86 78
 
87
-   Plugin works *correctly* if you see one sample for each resource every polling_interval (1 minute in this example)::
79
+#. For the ceilometer-agent-central, check that the samples are not duplicated.
80
+   For this check you may choose any metric collected by the ceilometer-agent-central.
81
+   All the Ceilometer metrics can be found in
82
+   `Measurements <http://docs.openstack.org/admin-guide/telemetry-measurements.html>`_ .
83
+   You may choose any section excepted *OpenStack Compute* and then select a metric with *Pollster Origin*.
84
+   For example, let's choose *storage.objects*.
88 85
 
89
-      root@node-2:~# ceilometer sample-list -m storage.objects  -l 10| grep storage.objects
90
-      | 65e486c734394d3ea321ae72639ebe91 | storage.objects | gauge | 0.0    | object | 2015-11-05T10:32:27 |
91
-      | 65e486c734394d3ea321ae72639ebe91 | storage.objects | gauge | 0.0    | object | 2015-11-05T10:31:29 |
86
+   The plugin **works correctly** if you see one sample for each resource type every
87
+   *polling interval* (1 minute in this example)::
92 88
 
93
-    
89
+     root@node-2:~# ceilometer sample-list -m storage.objects  -l 10| grep storage.objects
90
+     | 65e486c7... | storage.objects | gauge | 0.0    | object | 2015-11-05T10:32:27 |
91
+     | 65e486c7... | storage.objects | gauge | 0.0    | object | 2015-11-05T10:31:29 |
94 92
 
95
-   Plugin works *incorrectly* if there are duplications. In this example is seen that every
96
-   ``polling_interval`` there are 3 samples about one resource::
93
+   The plugin **works incorrectly** if there are duplicates. In this example, the plugin works
94
+   incorectly because there are three samples for the same resource type every *polling interval*::
97 95
 
98
-        root@node-2:~# ceilometer sample-list -m storage.objects  -l 20| grep storage.objects
99
-        | 65e486c734394d3ea321ae72639ebe91 | storage.objects | gauge | 0.0    | object ....|
100
-        | 65e486c734394d3ea321ae72639ebe91 | storage.objects | gauge | 0.0    | object ....|
101
-        | 65e486c734394d3ea321ae72639ebe91 | storage.objects | gauge | 0.0    | object ....|
102
-        | 65e486c734394d3ea321ae72639ebe91 | storage.objects | gauge | 0.0    | object ....|
103
-        | 65e486c734394d3ea321ae72639ebe91 | storage.objects | gauge | 0.0    | object ....| 
104
-        | 65e486c734394d3ea321ae72639ebe91 | storage.objects | gauge | 0.0    | object ....| 
96
+     root@node-2:~# ceilometer sample-list -m storage.objects  -l 20| grep storage.objects
97
+     | 65e486c7... | storage.objects | gauge | 0.0    | object | 2015-11-05T10:27:37 |
98
+     | 65e486c7... | storage.objects | gauge | 0.0    | object | 2015-11-05T10:27:26 |
99
+     | 65e486c7... | storage.objects | gauge | 0.0    | object | 2015-11-05T10:27:17 |
100
+     | 65e486c7... | storage.objects | gauge | 0.0    | object | 2015-11-05T10:26:38 |
101
+     | 65e486c7... | storage.objects | gauge | 0.0    | object | 2015-11-05T10:26:26 |
102
+     | 65e486c7... | storage.objects | gauge | 0.0    | object | 2015-11-05T10:26:17 |
105 103
 
106
-        .... 2015-11-05T10:27:37 |
107
-        .... 2015-11-05T10:27:26 |
108
-        .... 2015-11-05T10:27:17 |
109
-        .... 2015-11-05T10:26:38 |
110
-        .... 2015-11-05T10:26:26 |
111
-        .... 2015-11-05T10:26:17 |
104
+#. For the alarm evaluator, it is possible to see that everything works as expected
105
+   only from the logs::
112 106
 
107
+   # grep extract_my_subset /var/log/ceilometer/ceilometer-alarm-evaluator.log
113 108
 
114
-#. For the alarm evaluator, it is possible to see that everything works as expected only from the logs. Grep the
115
-   line "extract_my_subset". There should be different "My subset: [" results on each alarm evaluator instance.
109
+   There should be different *My subset: [* results for the ceilometer-alarm-evaluator instances.

doc/source/images/redis-plugin-8.0.png → doc/source/images/redis-plugin-8-0.png View File


doc/source/images/redis-plugin-on8.0.png → doc/source/images/redis-plugin-on8-0.png View File


+ 3
- 3
doc/source/index.rst View File

@@ -1,13 +1,13 @@
1
-========================================================================
1
+=====================================================
2 2
 Welcome to the Ceilometer Redis Plugin Documentation!
3
-========================================================================
3
+=====================================================
4 4
 
5 5
 .. toctree::
6 6
    :maxdepth: 2
7 7
 
8 8
    description
9
-   guide
10 9
    installation
10
+   guide
11 11
 
12 12
 Indices and Tables
13 13
 ==================

+ 17
- 20
doc/source/installation.rst View File

@@ -6,33 +6,30 @@ Installation Guide
6 6
 Install the Plugin
7 7
 ------------------
8 8
 
9
-To install the Redis plugin:
9
+To install the *Ceilometer Redis Plugin*, you need to follow these steps.
10 10
 
11
-#. Please refer to limitations before you proceed.
11
+#. Please refer to the :ref:`limitations` section before you proceed.
12 12
 
13
-#. Download the Redis plugin from the
13
+#. Download the plugin from the
14 14
    `Fuel Plugins Catalog <https://www.mirantis.com/products/openstack-drivers-and-plugins/fuel-plugins/>`_.
15 15
 
16
-#. Move the plugin's rpm to the
17
-   `Fuel Master node <https://docs.mirantis.com/openstack/fuel/fuel-8.0/quickstart-guide.html#quickstart-guide>`_ with secure copy (scp)::
16
+#. Copy the plugin's RPM file to the
17
+   `Fuel Master node
18
+   <http://docs.openstack.org/developer/fuel-docs/userdocs/fuel-install-guide/intro/intro_fuel_intro.html>`_
19
+   with secure copy (scp)::
18 20
 
19
-        scp fuel-plugin-ceilometer-redis/ceilometer-redis-1.0-1.0.0-1.noarch.rpm /
20
-        root@:<the_Fuel_Master_node_IP address>:/tmp
21
+     # scp fuel-plugin-ceilometer-redis/ceilometer-redis-1.0-1.0.0-1.noarch.rpm /
22
+     root@:<the_Fuel_Master_node_IP address>:/tmp
21 23
 
24
+#. Log into the Fuel Master node and install the plugin::
22 25
 
23
-#. Log into the Fuel Master node and install the Ceilometer Redis plugin::
24
-
25
-          ssh root@:<the_Fuel_Master_node_IP address>
26
-          cd /tmp
27
-          fuel plugins --install ceilometer-redis-1.0-1.0.0-1.noarch.rpm
28
-
26
+    # ssh root@:<the_Fuel_Master_node_IP address>
27
+    [root@fuel-master ~]# cd /tmp
28
+    [root@fuel-master ~]# fuel plugins --install ceilometer-redis-1.0-1.0.0-1.noarch.rpm
29 29
 
30 30
 #. Verify that the plugin is installed correctly::
31 31
 
32
-     [root@fuel-master ~]# fuel plugins list
33
-     id | name             | version       | package_version
34
-     ---|------------------|---------------|----------------
35
-     4  | ceilometer-redis | 1.0.2         | 3.0.0
36
-
37
-
38
-
32
+    [root@fuel-master ~]# fuel plugins list
33
+    id | name             | version       | package_version
34
+    ---|------------------|---------------|----------------
35
+    4  | ceilometer-redis | 1.0.2         | 3.0.0

Loading…
Cancel
Save