USERDOCAPAP-240 final updates to both docs

2 files changed, 54 insertions, 13 deletions

diff --git a/book-enea-nfv-core-release-info/doc/about_release.xml b/book-enea-nfv-core-release-info/doc/about_release.xml
index e0c6e2f..63827c5 100644
--- a/book-enea-nfv-core-release-info/doc/about_release.xml
+++ b/book-enea-nfv-core-release-info/doc/about_release.xml
@@ -181,7 +181,8 @@
       </tgroup>
     </informaltable>
 
-    <para>Galera cluster for MySQL consists of:</para>
+    <para><emphasis role="bold">Galera cluster for MySQL consists
+    of:</emphasis></para>
 
     <informaltable>
       <tgroup cols="2">
diff --git a/book-enea-nfv-core-release-info/doc/known_bugs_and_limitations.xml b/book-enea-nfv-core-release-info/doc/known_bugs_and_limitations.xml
index 10104c8..c5fbfbb 100644
--- a/book-enea-nfv-core-release-info/doc/known_bugs_and_limitations.xml
+++ b/book-enea-nfv-core-release-info/doc/known_bugs_and_limitations.xml
@@ -17,6 +17,46 @@
 
     <orderedlist>
       <listitem>
+        <para>Live migration fails on ThunderX NUMA nodes</para>
+
+        <itemizedlist>
+          <listitem>
+            <para>Description and Impact:</para>
+
+            <para>Rally Nova tests are failing for the
+            <filename>nosdn-vlan_doctor_dpdk-ha</filename> scenario on
+            ThunderX NUMA nodes. The issue is not reproducible on the x86
+            architecture nor on aarch64 (for non dpdk scenarios).</para>
+          </listitem>
+
+          <listitem>
+            <para>Workaround: N/A.</para>
+          </listitem>
+        </itemizedlist>
+      </listitem>
+
+      <listitem>
+        <para> Instances fail to boot when using a direct port (SR-IOV) on
+        ThunderX</para>
+
+        <itemizedlist>
+          <listitem>
+            <para>Description and Impact:</para>
+
+            <para>Deployment is successful with SR-IOV enabled interfaces
+            however, instances fail to boot when a direct bound (SR-IOV) port
+            is added. This has been tested using a SR-IOV capable PCI Express
+            Network Interface. As a consequence it is impossible to
+            passthrough a SR-IOV port on ThunderX.</para>
+          </listitem>
+
+          <listitem>
+            <para>Workaround: N/A.</para>
+          </listitem>
+        </itemizedlist>
+      </listitem>
+
+      <listitem>
         <para>Security groups are not working correctly for ICMP traffic in
         deployments with OpenDaylight.</para>
 
@@ -24,7 +64,7 @@
           <listitem>
             <para>Description and Impact:</para>
 
-            <orderedlist>
+            <itemizedlist>
               <listitem>
                 <para>When OPNFV is deployed with OpenDaylight as an SDN
                 controller, the Security Groups rules pertaining to ICMP do
@@ -37,7 +77,7 @@
                 <para>This reproduces on aarch64. On x86 the security groups
                 work correctly.</para>
               </listitem>
-            </orderedlist>
+            </itemizedlist>
           </listitem>
 
           <listitem>
@@ -54,7 +94,7 @@
           <listitem>
             <para>Description and Impact:</para>
 
-            <orderedlist>
+            <itemizedlist>
               <listitem>
                 <para>After a fresh deploy of OPNFV with OpenDaylight and the
                 Service Function Chaining scenario configurations, instances
@@ -66,7 +106,7 @@
                 <para>The SFC VNFs are not reachable via SSH for management
                 and configuration.</para>
               </listitem>
-            </orderedlist>
+            </itemizedlist>
           </listitem>
 
           <listitem>
@@ -83,7 +123,7 @@
           <listitem>
             <para>Description and Impact:</para>
 
-            <orderedlist>
+            <itemizedlist>
               <listitem>
                 <para>When adding or removing nodes via Fuel installer on an
                 OPNFV deployment that uses OpenDaylight, flows in
@@ -98,7 +138,7 @@
                 compute node cannot be reached by floating IP. Scale-out and
                 scale-in operations are flawed.</para>
               </listitem>
-            </orderedlist>
+            </itemizedlist>
           </listitem>
 
           <listitem>
@@ -116,7 +156,7 @@
           <listitem>
             <para>Description and Impact:</para>
 
-            <orderedlist>
+            <itemizedlist>
               <listitem>
                 <para>When the user tries to hot-plug a network port to a
                 running instance, this fails due to virtio negotiation failure
@@ -128,7 +168,7 @@
               <listitem>
                 <para>This reproduces on aarch64.</para>
               </listitem>
-            </orderedlist>
+            </itemizedlist>
           </listitem>
 
           <listitem>
@@ -148,7 +188,7 @@
           <listitem>
             <para>Description and Impact:</para>
 
-            <orderedlist>
+            <itemizedlist>
               <listitem>
                 <para>The Configuration tests from the Fuel Healthcheck fail
                 when the OPNFV cluster operates with the default credentials.
@@ -159,14 +199,14 @@
               <listitem>
                 <para>This is architecture independent.</para>
               </listitem>
-            </orderedlist>
+            </itemizedlist>
           </listitem>
 
           <listitem>
             <para>Workaround: In order to make these 3 test cases pass, the
             user needs to:</para>
 
-            <orderedlist>
+            <itemizedlist>
               <listitem>
                 <para>Change the credentials for the root user on the Fuel
                 Master node: after logging on as root on the master node,
@@ -188,7 +228,7 @@
                 before deploy or you will need to redeploy to have the changes
                 applied.</para>
               </listitem>
-            </orderedlist>
+            </itemizedlist>
           </listitem>
         </itemizedlist>
       </listitem>