From ce4f54732f1eda5a4d88a13c3a9d42d2f5456559 Mon Sep 17 00:00:00 2001
From: nerminamiller <nerminamiller@gmail.com>
Date: Thu, 3 Oct 2013 11:36:12 -0400
Subject: [PATCH] Add evacuate instances to Cloud Admin Guide Clarify that
 evacuate method is preferred over manual for node recovery Edit broken and
 obsolete external guide references Remove gerunds in related files Address
 request for stylistic edits from review Address linking issues from review

Change-Id: Iccf188ad89a8cc277966cb9c0a530ba24613127b
Closes-Bug:#1222735
---
 doc/admin-guide-cloud/ch_compute.xml          | 33 +++++++++----------
 doc/common/section_nova_cli_evacuate.xml      |  4 +--
 .../section_compute-configure-migrations.xml  |  9 +++--
 3 files changed, 21 insertions(+), 25 deletions(-)

diff --git a/doc/admin-guide-cloud/ch_compute.xml b/doc/admin-guide-cloud/ch_compute.xml
index 8d62ee6160..0a83332d48 100644
--- a/doc/admin-guide-cloud/ch_compute.xml
+++ b/doc/admin-guide-cloud/ch_compute.xml
@@ -2010,9 +2010,8 @@ local0.error    @@172.20.1.43:1024</programlisting></para>
 
         <section xml:id="section_live-migration-usage">
             <title>Migration</title>
-        <para>Before starting migrations, review the <link xlink:href="http://docs.openstack.org/trunk/config-reference/content/configuring-openstack-compute-basics.html#section_configuring-compute-migrations"
-                >Configuring Migrations</link> section in the
-                <citetitle>Configuration Reference Guide</citetitle>.</para>
+            <para>Before starting migrations, review the <link xlink:href="http://docs.openstack.org/trunk/config-reference/content/configuring-openstack-compute-basics.html#section_configuring-compute-migrations">Configure migrations</link> section in <citetitle>OpenStack Configuration
+                    Reference</citetitle>.</para>
             <para>Migration provides a scheme to migrate running
                 instances from one OpenStack Compute server to another
                 OpenStack Compute server.</para>
@@ -2082,10 +2081,8 @@ HostC            p2            5     10240     150
                                 memory (MB)</para>
                         </listitem>
                         <listitem>
-                            <para><emphasis role="bold"
-                                   >hdd:</emphasis>total amount of
-                                space for
-                                NOVA-INST-DIR/instances(GB)</para>
+                            <para><emphasis role="bold">hdd:</emphasis>total amount of space for
+                                NOVA-INST-DIR/instances (GB)</para>
                         </listitem>
                         <listitem>
                             <para><emphasis role="bold">1st line shows
@@ -2127,23 +2124,25 @@ HostC            p2            5     10240     150
                                    <command>live-migration</command>,
                                 under the default Compute
                                 configuration options the instances
-                                are suspended before migration.</para>
-                        </note><!--<para>See
-                            the <link linkend="configuring-migrations">Configuring Migrations</link>
-                            section for more details.</para>--></para>
+                                are suspended before migration.</para> 
+                            <para>See <link xlink:href="http://docs.openstack.org/trunk/config-reference/content/configuring-openstack-compute-basics.html#section_configuring-compute-migrations">Configure migrations</link> in <citetitle>OpenStack Configuration Reference</citetitle> for more details.</para>
+                        </note>
+                </para>
                 </step>
             </procedure>
         </section>
         <section xml:id="section_nova-compute-node-down">
             <title>Recover from a failed compute node</title>
-            <para>If you have deployed OpenStack Compute with a shared
-                file system, you can quickly recover from a failed
-                compute node.</para>
+            <para>If you have deployed Compute with a shared file system, you can quickly recover
+                from a failed compute node. Of the two methods covered in the following sections,
+                the evacuate API is the preferred method even in the absence of shared storage. The
+                evacuate API provides many benefits over manual recovery, such as re-attachment of
+                volumes and floating IPs. </para>
+            <xi:include href="../common/section_nova_cli_evacuate.xml"/>
             <section xml:id="nova-compute-node-down-manual-recovery">
                 <title>Manual recovery</title>
-                <para>For KVM/libvirt compute node recovery refer to
-                    section above, while the guide below may be
-                    applicable for other hypervisors.</para>
+                <para>For KVM/libvirt compute node recovery, see the previous section. Use the
+                    following procedure for other hypervisors.</para>
                 <procedure>
                     <title>To work with host information</title>
                     <step>
diff --git a/doc/common/section_nova_cli_evacuate.xml b/doc/common/section_nova_cli_evacuate.xml
index 10499e6ecd..a951f1f075 100644
--- a/doc/common/section_nova_cli_evacuate.xml
+++ b/doc/common/section_nova_cli_evacuate.xml
@@ -41,9 +41,7 @@
         <step>
             <para>To preserve the user disk data on the evacuated
                 server, deploy OpenStack Compute with shared
-                filesystem. To configure your system, see <link
-                    xlink:href="http://docs.openstack.org/trunk/config-reference/content/configuring-openstack-compute-basics.html#section_configuring-compute-migrations"
-                    >Configure migrations section</link>. In this
+                filesystem. To configure your system, see <link	xlink:href="http://docs.openstack.org/trunk/config-reference/content/configuring-openstack-compute-basics.html#section_configuring-compute-migrations">Configure migrations</link> in <citetitle>OpenStack Configuration Reference</citetitle>. In this
                 example, the password remains unchanged.</para>
             <screen><prompt>$</prompt> <userinput>nova evacuate <replaceable>evacuated_server_name</replaceable> <replaceable>host_b</replaceable> --on-shared-storage</userinput>    </screen>
         </step>
diff --git a/doc/config-reference/compute/section_compute-configure-migrations.xml b/doc/config-reference/compute/section_compute-configure-migrations.xml
index f92900138a..f556a8b609 100644
--- a/doc/config-reference/compute/section_compute-configure-migrations.xml
+++ b/doc/config-reference/compute/section_compute-configure-migrations.xml
@@ -8,7 +8,7 @@
          xmlns:ns="http://docbook.org/ns/docbook"
          version="5.0">
    <?dbhtml stop-chunking?>
-    <title>Configuring Migrations</title>
+    <title>Configure migrations</title>
   <note>
     <para>This feature is for cloud administrators only. If your cloud is configured to use cells,
       you can perform live migration within a cell, but not between cells.</para>
@@ -67,10 +67,9 @@
           </listitem>
         </itemizedlist>
         <note>
-          <para>Migrations done by the Compute service do not use libvirt's live migration
-            functionality by default. Because of this, guests are suspended before migration and may
-            therefore experience several minutes of downtime. See the section on True Migration for
-            KVM and Libvirt in the OpenStack Compute Administration Guide for more details.</para>
+          <para>Because the Compute service does not use libvirt's live migration functionality by
+          default, guests are suspended before migration and may therefore experience several
+          minutes of downtime. See the <xref linkend="true-live-migration-kvm-libvirt"/> section for more details.</para>
         </note>
         <note>
           <para>This guide assumes the default value for <literal>instances_path</literal> in your