1 files changed, 14 insertions, 14 deletions

diff --git a/book-enea-nfv-core-installation-guide/doc/high_availability.xml b/book-enea-nfv-core-installation-guide/doc/high_availability.xml
index 4fe02fe..6d1a9c7 100644
--- a/book-enea-nfv-core-installation-guide/doc/high_availability.xml
+++ b/book-enea-nfv-core-installation-guide/doc/high_availability.xml
@@ -305,7 +305,7 @@
 
       <para>The Zabbix configuration dashboard is available at the same IP
       address where OpenStack can be reached, e.g.
-      <literal>http://&lt;vip__zbx_vip_mgmt&gt;/zabbix</literal>.</para>
+      <literal>http://10.0.6.42/zabbix</literal>.</para>
 
       <para>To forward zabbix events to Vitrage, a new media script needs to
       be created and associated with a user. Follow the steps below as a
@@ -550,8 +550,8 @@ root@node-6:~# systemctl restart vitrage-graph</programlisting>
     <title>Pacemaker High Availability</title>
 
     <para>Many of the OpenStack solutions which offer High Availability
-    characteristics employ pacemaker for achieving highly available OpenStack
-    services. Traditionally pacemaker has been used for managing only the
+    characteristics employ Pacemaker for achieving highly available OpenStack
+    services. Traditionally Pacemaker has been used for managing only the
     control plane services, so it can effectively provide redundancy and
     recovery for the Controller nodes only. A reason for this is that
     Controller nodes and Compute nodes essentially have very different High
@@ -572,9 +572,9 @@ root@node-6:~# systemctl restart vitrage-graph</programlisting>
     understood and experimented with, and the basis for this is Pacemaker
     using Corosync underneath.</para>
 
-    <para>Extending the use of pacemaker to Compute nodes was thought as a
+    <para>Extending the use of Pacemaker to Compute nodes was thought as a
     possible solution for providing VNF high availability, but the problem
-    turned out to be more complicated. On one hand, pacemaker as a clustering
+    turned out to be more complicated. On one hand, Pacemaker as a clustering
     tool, can only scale properly up to a limited number of nodes, usually
     less than 128. This poses a problem for large scale deployments where
     hundreds of compute nodes are required. On the other hand, Compute node
@@ -584,20 +584,20 @@ root@node-6:~# systemctl restart vitrage-graph</programlisting>
     <section id="pm_remote">
       <title>Pacemaker Remote</title>
 
-      <para>As mentioned earlier, pacemaker and corosync do not scale well
+      <para>As mentioned earlier, Pacemaker and corosync do not scale well
       over a large cluster, since each node has to talk to every other,
       essentially creating a mesh configuration. A solution to this problem
       could be partitioning the cluster into smaller groups, but this has its
       limitations and it is generally difficult to manage.</para>
 
       <para>A better solution is using <literal>pacemaker-remote</literal>, a
-      feature of pacemaker, which allows for extending the cluster beyond the
-      usual limits by using the pacemaker monitoring capabilities. It
+      feature of Pacemaker, which allows for extending the cluster beyond the
+      usual limits by using the Pacemaker monitoring capabilities. It
       essentially creates a new type of resource which enables adding light
       weight nodes to the cluster. More information about pacemaker-remote can
       be found on the official clusterlabs website.</para>
 
-      <para>Please note that at this moment pacemaker remote must be
+      <para>Please note that at this moment Pacemaker remote must be
       configured manually after deployment. Here are the manual steps for
       doing so:</para>
 
@@ -629,7 +629,7 @@ controller, vitrage       |               |      1 |        1</programlisting>
         </listitem>
 
         <listitem>
-          <para>Each controller has a unique pacemaker authkey. One needs to
+          <para>Each controller has a unique Pacemaker authkey. One needs to
           be kept and propagated to the other servers. Assuming node-1, node-2
           and node-3 are the controllers, execute the following from the Fuel
           console:</para>
@@ -711,7 +711,7 @@ RemoteOnline: [ node-4.domain.tld node-5.domain.tld ]</programlisting>
       <title>Pacemaker Fencing</title>
 
       <para>ENEA NFV Core 1.0 makes use of the fencing capabilities of
-      pacemaker to isolate faulty nodes and trigger recovery actions by means
+      Pacemaker to isolate faulty nodes and trigger recovery actions by means
       of power cycling the failed nodes. Fencing is configured by creating
       <literal>STONITH</literal> type resources for each of the servers in the
       cluster, both Controller nodes and Compute nodes. The
@@ -756,7 +756,7 @@ controller, vitrage       |               |      1 |        1</programlisting>
         </listitem>
 
         <listitem>
-          <para>Configure pacemaker fencing resources. This needs to be done
+          <para>Configure Pacemaker fencing resources. This needs to be done
           once on one of the controllers. The parameters will vary, depending
           on the BMC addresses of each node and credentials.</para>
 
@@ -779,7 +779,7 @@ ipaddr=10.0.100.155 login=ADMIN passwd=ADMIN op monitor interval="60s"</programl
 
         <listitem>
           <para>Activate fencing by enabling the <literal>stonith</literal>
-          property in pacemaker (disabled by default). This also needs to be
+          property in Pacemaker (disabled by default). This also needs to be
           done only once, on one of the controllers.</para>
 
           <programlisting>[root@node-1:~]# pcs property set stonith-enabled=true</programlisting>
@@ -805,7 +805,7 @@ ipaddr=10.0.100.155 login=ADMIN passwd=ADMIN op monitor interval="60s"</programl
     <para>The work for Compute node High Availability is captured in an
     OpenStack user story and documented upstream, showing proposed solutions,
     summit talks and presentations. A number of these solutions make use of
-    OpenStack Resource Agents, which are a set of specialized pacemaker
+    OpenStack Resource Agents, which are a set of specialized Pacemaker
     resources capable of identifying failures in compute nodes and can perform
     automatic evacuation of the instances affected by these failures.</para>