ENEA NFV Core 1.1 Release Notes & Installation Guide Updates

4 files changed, 155 insertions, 221 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 5347e33..bd4fa95 100644
--- a/book-enea-nfv-core-release-info/doc/about_release.xml
+++ b/book-enea-nfv-core-release-info/doc/about_release.xml
@@ -7,11 +7,11 @@
   <section id="intro">
     <title>Introduction</title>
 
-    <para>Enea NFV Core is based on the OPNFV <emphasis
-    role="bold">Danube</emphasis> release, and is compatible with the <ulink
+    <para>Enea NFV Core is Open Platform for NFV (OPNFV) compliant and it is
+    compatible with the <ulink
     url="http://www.etsi.org/deliver/etsi_gs/NFV/001_099/002/01.02.01_60/gs_NFV002v010201p.pdf">ETSI
     NFV reference architecture</ulink>. It leverages several OPNFV community
-    projects, including Functest, Yardstick, Doctor, Fuel, and Armband.</para>
+    projects, including Functest, Yardstick, Doctor, Fuel and Armband.</para>
 
     <para>This release consists of the following components:</para>
 
@@ -29,19 +29,13 @@
           <row>
             <entry>Installer</entry>
 
-            <entry>Fuel v.10</entry>
-          </row>
-
-          <row>
-            <entry>OPNFV version</entry>
-
-            <entry>Danube</entry>
+            <entry>Fuel v.11</entry>
           </row>
 
           <row>
             <entry>OpenStack Version</entry>
 
-            <entry>OpenStack Newton</entry>
+            <entry>OpenStack Ocata</entry>
           </row>
 
           <row>
@@ -53,7 +47,7 @@
           <row>
             <entry>Pacemaker</entry>
 
-            <entry>2:9.1.3-1~u16.04+mos4</entry>
+            <entry>1.1.14-2+enc1~u16.04+mos1</entry>
           </row>
 
           <row>
@@ -65,33 +59,31 @@
           <row>
             <entry>Open vSwitch</entry>
 
-            <entry>2.7.0-0ubuntu3 plus other patches</entry>
+            <entry>2.9.0-1+enc1~ubuntu1</entry>
           </row>
 
           <row>
             <entry>DPDK</entry>
 
-            <entry>16.11.2-3 upgraded to 17.02.1 plus other patches</entry>
+            <entry>17.11.2-1+enc1~ubuntu0.1</entry>
           </row>
 
           <row>
             <entry>Qemu-KVM</entry>
 
-            <entry align="left">1:2.8+dfsg-3ubuntu1 upgraded to
-            1:2.9~rc1+dfsg-0+amos1~u16.04 plus other patches</entry>
+            <entry align="left">2.9+dfsg-0+enc5~u16.04</entry>
           </row>
 
           <row>
             <entry>EDK2</entry>
 
-            <entry align="left">0~20160813.de74668f-1ubuntu0.1 plus other
-            patches</entry>
+            <entry align="left">20160813.de74668f-1+enc1~u16.04</entry>
           </row>
 
           <row>
             <entry>Libvirt</entry>
 
-            <entry>3.5.0-1ubuntu3 plus other patches</entry>
+            <entry>3.5.0-1+enc3~u16.04</entry>
           </row>
 
           <row>
@@ -103,13 +95,13 @@
           <row>
             <entry>Aodh</entry>
 
-            <entry>3.0.2-1~u16.04+mos0</entry>
+            <entry>4.0.3-2+enc1~u16.04</entry>
           </row>
 
           <row>
             <entry>Ceilometer</entry>
 
-            <entry>1:7.0.3-1~u16.04+mos2</entry>
+            <entry>8.1.4-2+enc1~u16.04</entry>
           </row>
 
           <row>
@@ -121,7 +113,7 @@
           <row>
             <entry>Heat</entry>
 
-            <entry>1:7.0.2-1~u16.04+mos4</entry>
+            <entry>8.0.6-1+enc2~u16.04.</entry>
           </row>
 
           <row>
@@ -131,51 +123,51 @@
           </row>
 
           <row>
-            <entry>cloud-init</entry>
+            <entry>Cloud-init</entry>
 
-            <entry>0.7.9-90-g61eb03fe-0+amos1~u16.04</entry>
+            <entry>0.7.9-90-g61eb03fe-0+enc1~u16.04</entry>
           </row>
 
           <row>
             <entry>Ceph Object Storage</entry>
 
-            <entry>10.2.6-0ubuntu0.16.04.1</entry>
+            <entry>10.2.6-0+enc2~u16.04</entry>
           </row>
 
           <row>
             <entry>RabbitMQ Messaging</entry>
 
-            <entry>3.6.6-1+amos1~u16.04+mos1</entry>
+            <entry>3.6.6-1+enc1~u16.04+mos1</entry>
           </row>
 
           <row>
             <entry>Zabbix</entry>
 
-            <entry>1:2.4.8-1+trusty plus other patches</entry>
+            <entry>2.4.8-1+enc2~u16.04</entry>
           </row>
 
           <row>
-            <entry>Vitrage</entry>
+            <entry>Vitrage / Fuel plugin Vitrage</entry>
 
-            <entry>1.0.2.dev5</entry>
+            <entry>1.7.0 / 1.0.1-rc4</entry>
           </row>
 
           <row>
             <entry>Erlang</entry>
 
-            <entry>1:18.3.4+dfsg-1~u16.04+mos1</entry>
+            <entry>18.3.4+dfsg-1+enc1~u16.04+mos1</entry>
           </row>
 
           <row>
             <entry>Percona XtraBackup</entry>
 
-            <entry>2.4.5-1+amos1~u16.04 plus other patches</entry>
+            <entry>2.4.5-1+enc1~u16.04</entry>
           </row>
 
           <row>
             <entry>MongoDB</entry>
 
-            <entry>1:2.6.10-0+amos1~u16.04</entry>
+            <entry>2.6.10-0+enc1~u16.04</entry>
           </row>
         </tbody>
       </tgroup>
@@ -198,13 +190,13 @@
           <row>
             <entry>MySQL-wsrep</entry>
 
-            <entry>5.6.36</entry>
+            <entry>5.6.35-0+enc1~u16.04+mos1</entry>
           </row>
 
           <row>
-            <entry>Galera</entry>
+            <entry>Galera-3</entry>
 
-            <entry>3.21</entry>
+            <entry>25.3.15-1</entry>
           </row>
 
           <row>
@@ -233,13 +225,7 @@
           <row>
             <entry>OpenDaylight</entry>
 
-            <entry>Boron</entry>
-          </row>
-
-          <row>
-            <entry>Congress</entry>
-
-            <entry>4.0.0 with Doctor datasource</entry>
+            <entry>Oxygen</entry>
           </row>
         </tbody>
       </tgroup>
@@ -259,6 +245,11 @@
       </listitem>
 
       <listitem>
+        <para><trademark class="registered">Enea</trademark> NFV Core Server
+        Requirement Specification</para>
+      </listitem>
+
+      <listitem>
         <para><olink targetdoc="book_enea_nfv_core_installation_guide"
         targetptr="book_enea_nfv_core_installation_guide"><trademark
         class="registered">Enea</trademark> NFV Core User's Guide Installation
@@ -266,7 +257,7 @@
       </listitem>
 
       <listitem condition="hidden">
-        <para> Enea Linux Open Source Report</para>
+        <para>Enea Linux Open Source Report</para>
       </listitem>
 
       <listitem condition="hidden">
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 bc682ab..1aa394d 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
@@ -44,29 +44,35 @@
       </listitem>
 
       <listitem>
-        <para>Instances fail to boot when using a direct port (SR-IOV) on
-        ThunderX</para>
+        <para>ThunderX integrated NICs cannot be used for SR-IOV</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>
+            <para>For the moment ENEA NFV Core is missing the support to
+            configure ThunderX integrated NICs for deployment. Furthermore,
+            ThunderX integrated NICs cannot be used for SR-IOV even if
+            configured manually after deployment. This happens because
+            ThunderX integrated NICs are themseleves virtual functions and are
+            incorrectly handled by libvirt when trying to assign them to a
+            virtual machine.</para>
+
+            <para>It is however possible to deploy with SR-IOV over add-on
+            interfaces via the PCI-E expansion slots.</para>
           </listitem>
 
           <listitem>
-            <para>Workaround: N/A.</para>
+            <para>Workaround: there is no workaround for this issue. As an
+            alternative, the user can configure an external PCI-E NIC for
+            SR-IOV.</para>
           </listitem>
         </itemizedlist>
       </listitem>
 
       <listitem>
-        <para>Security groups are not working correctly for ICMP traffic in
-        deployments with OpenDaylight.</para>
+        <para>ThunderX integrated NICs cannot be used for PCI passthrough with
+        direct-physical bound Neutron ports</para>
 
         <itemizedlist>
           <listitem>
@@ -74,52 +80,32 @@
 
             <itemizedlist>
               <listitem>
-                <para>When OPNFV is deployed with OpenDaylight as an SDN
-                controller, the Security Groups rules pertaining to ICMP do
-                not work as expected. The OpenFlow rules describing the ICMP
-                rules are inconsistent, so VMs can be pinged even when this is
-                not desired.</para>
-              </listitem>
-
-              <listitem>
-                <para>This reproduces on aarch64. On x86 the security groups
-                work correctly.</para>
+                <para>PCI Passthrough using direct-physical bound ports also
+                uses the neutron-sriov-agent. Because the interfaces are
+                represented as virtual functions, it will be impossible to use
+                Neutron ports bound as direct-physical (the Nova driver will
+                identify them as type-VF, not type-PF).</para>
+
+                <para>Due to this, it is not possible to claim PCI devices
+                using direct-physical bound ports.</para>
               </listitem>
             </itemizedlist>
-          </listitem>
-
-          <listitem>
-            <para>Workaround: N/A.</para>
-          </listitem>
-        </itemizedlist>
-      </listitem>
-
-      <listitem>
-        <para>Virtual instances do not get IP from DHCP in SFC scenarios with
-        ODL</para>
-
-        <itemizedlist>
-          <listitem>
-            <para>Description and Impact:</para>
 
             <itemizedlist>
               <listitem>
-                <para>After a fresh deploy of OPNFV with OpenDaylight and the
-                Service Function Chaining scenario configurations, instances
-                fail to get IP from DHCP, due to OpenDaylight
-                malfunctioning.</para>
-              </listitem>
-
-              <listitem>
-                <para>The SFC VNFs are not reachable via SSH for management
-                and configuration.</para>
+                <para>It is however possible to passthrough any device using
+                the PCI alias method, which requries configuring a whitelist
+                of PCI devices and assigning an alias which is set as metadata
+                in the Nova flavor.</para>
               </listitem>
             </itemizedlist>
           </listitem>
 
           <listitem>
-            <para>Workaround: Restarting OpenDaylight via
-            <literal>systemctl</literal> fixes the problem.</para>
+            <para>Workaround:</para>
+
+            <para>There is no workaround for this issue. As an alternative,
+            the user can configure a PCI alias instead.</para>
           </listitem>
         </itemizedlist>
       </listitem>
@@ -242,106 +228,6 @@
       </listitem>
 
       <listitem>
-        <para>Fuel Healthcheck Stack update test fails</para>
-
-        <itemizedlist>
-          <listitem>
-            <para>Description and Impact:</para>
-
-            <para>The Platform test case number 5 (Update stack) from the Fuel
-            Healthcheck sometimes fails. This has no impact on the overal
-            cluster functionality.</para>
-          </listitem>
-
-          <listitem>
-            <para>Workaround: N/A.</para>
-          </listitem>
-        </itemizedlist>
-      </listitem>
-
-      <listitem>
-        <para>Issue #1 with Openstack Resource Agents and Compute Fencing
-        functionality</para>
-
-        <itemizedlist>
-          <listitem>
-            <para>Description and Impact:</para>
-
-            <para>In an OPNFV deployment that uses Openstack Resource Agents,
-            the neutron-openvswitch-agent is killed by Pacemaker when booting,
-            due to Pacemaker misconfiguration.</para>
-          </listitem>
-
-          <listitem>
-            <para>Workaround:</para>
-
-            <para>Starting the <literal>systemd</literal> service manually
-            makes it run successfully. Enea NFV Core 1.0.1 is shipped without
-            Openstack Resource Agents, therefore this issue should not affect
-            the user.</para>
-          </listitem>
-        </itemizedlist>
-      </listitem>
-
-      <listitem>
-        <para>Issue #2 with Openstack Resource Agents and Compute Fencing
-        functionality</para>
-
-        <itemizedlist>
-          <listitem>
-            <para>Description and Impact:</para>
-
-            <para>In an OPNFV deployment that uses Openstack Resource Agents,
-            when we configure the <literal>fence_compute</literal> as a
-            Pacemaker resource, the Controller nodes start to reboot each
-            other endlessly.</para>
-          </listitem>
-
-          <listitem>
-            <para>Workaround:</para>
-
-            <para>Enea NFV Core 1.0.1 is shipped without Openstack Resource
-            Agents, therefore this issue should not affect the user.</para>
-          </listitem>
-        </itemizedlist>
-      </listitem>
-
-      <listitem>
-        <para>Virtual instances are not affected by removing a node from the
-        Ceph Storage Cluster</para>
-
-        <itemizedlist>
-          <listitem>
-            <para>Description and Impact:</para>
-
-            <para>Engineering wanted to validate the survival of storage
-            systems when a single disk is removed, without causing data loss.
-            Without physical access to the test setup, this test is not
-            feasible.</para>
-          </listitem>
-
-          <listitem>
-            <para>Workaround:</para>
-
-            <itemizedlist>
-              <listitem>
-                <para>The chosen approach was to validate what happens to the
-                Ceph cluster, when network connectivity is lost for the
-                Storage interface of one of the nodes. No impact was observed
-                when running an instance using Ceph for volume storage.</para>
-              </listitem>
-
-              <listitem>
-                <para><ulink
-                url="http://ceph.com/geen-categorie/admin-guide-replacing-a-failed-disk-in-a-ceph-cluster/">Reference
-                information</ulink></para>
-              </listitem>
-            </itemizedlist>
-          </listitem>
-        </itemizedlist>
-      </listitem>
-
-      <listitem>
         <para>Offline Deploy with Fuel fails at times</para>
 
         <itemizedlist>
@@ -394,44 +280,67 @@
       </listitem>
 
       <listitem>
-        <para>Fuel Healthcheck Stack creation with wait condition test,
-        fails</para>
+        <para>On Mixed Arch Deployment, only the aarch64 TestVM Cirros image
+        will be installed by Fuel</para>
 
         <itemizedlist>
           <listitem>
             <para>Description and Impact:</para>
 
-            <para>The platform test case (create stack with wait condition)
-            from the Fuel Healthcheck, fails. This has no impact on overall
-            cluster functionality.</para>
+            <para>Due to the fact that Fuel will only deploy the aarch64
+            image, Yardstick, Functest, and certain Health Check tests will
+            not work. These test suites are dependent on a single image name
+            at a time, and do not know on how to place instances on the
+            Compute for images that each require a different arch.</para>
+
+            <para>To have both testVM images, the user must add the x86_64
+            image manually.</para>
           </listitem>
 
           <listitem>
-            <para>Workaround: N/A.</para>
+            <para>There is no workaround for the test suites failures.</para>
           </listitem>
         </itemizedlist>
       </listitem>
 
       <listitem>
-        <para>On Mixed Arch Deployment, only the aarch64 TestVM Cirros image
-        will be installed by Fuel</para>
+        <para>Removing QoS policies is unreliable</para>
 
         <itemizedlist>
           <listitem>
             <para>Description and Impact:</para>
 
-            <para>Due to the fact that Fuel will only deploy the aarch64
-            image, Yardstick, Functest, and certain Health Check tests will
-            not work. These test suites are dependent on a single image name
-            at a time, and do not know on how to place instances on the
-            Compute for images that each require a different arch.</para>
+            <para>When removing per port bandwidth limiting QoS policies, all
+            traffic is suddenly dropped. On the the other hand, when removing
+            QoS policies configured at Openstack network level, traffic flows
+            as if the rules are still there.</para>
+          </listitem>
 
-            <para>To have both testVM images, the user must add the x86_64
-            image manually.</para>
+          <listitem>
+            <para>There is no workaround.</para>
+          </listitem>
+        </itemizedlist>
+      </listitem>
+
+      <listitem>
+        <para>Enabling Ceph for Glance and Nova ephemeral storage makes the
+        deployment fail on aarch64</para>
+
+        <itemizedlist>
+          <listitem>
+            <para>Description and Impact:</para>
+
+            <para>There are multiple configurable Storage Backends in Fuel
+            settings. Enabling Ceph RBD for images (Glance) and Ceph RBD for
+            ephemeral volumes (Nova), makes the deployment fail at the CEPH
+            Ready Check performed on the primary Controller node. This only
+            occurs when using aarch64 nodes; on x86_64, deployment does not
+            fail</para>
           </listitem>
 
           <listitem>
-            <para>There is no workaround for the test suites failures.</para>
+            <para>There is no workaround. The user should not enable these
+            options.</para>
           </listitem>
         </itemizedlist>
       </listitem>
diff --git a/book-enea-nfv-core-release-info/doc/main_changes.xml b/book-enea-nfv-core-release-info/doc/main_changes.xml
index 53c1f0f..b79237d 100644
--- a/book-enea-nfv-core-release-info/doc/main_changes.xml
+++ b/book-enea-nfv-core-release-info/doc/main_changes.xml
@@ -1,12 +1,58 @@
 <?xml version="1.0" encoding="ISO-8859-1"?>
 <chapter id="main_changes">
-  <title>Main Changes</title>
+  <title>Main Changes in this Release</title>
+
+  <section id="sw_comps_upd">
+    <title>Software Components Updates</title>
+
+    <itemizedlist>
+      <listitem>
+        <para>Migrated from Openstack Newton to OpenStack Ocata.</para>
+      </listitem>
+
+      <listitem>
+        <para>Installer has been upgraded from Fuel 10 to Fuel 11.</para>
+      </listitem>
+
+      <listitem>
+        <para>Upgraded OpenVSwitch from 2.7 to 2.9</para>
+      </listitem>
+
+      <listitem>
+        <para>Upgraded DPDK from 16.11 to 17.11.</para>
+      </listitem>
+    </itemizedlist>
+  </section>
 
   <section id="mixed_arch">
     <title>Mixed Arch Deployment</title>
 
-    <para>Enea NFV Core <phrase>1.1</phrase> can be installed on a cluster
-    consisting of servers with mixed CPU architectures. The user can deploy
-    x86 Controllers and a combination of x86 and aarch64 Compute nodes.</para>
+    <para>Enea NFV Core 1.1 can be installed on a cluster consisting of
+    servers with mixed CPU architectures. The user can deploy x86 controllers
+    and a combination of x86 and aarch64 compute nodes.</para>
+  </section>
+
+  <section id="dvr">
+    <title>Distributed Virtual Routing</title>
+
+    <para>DVR support was validated, as it provides more efficient routing and
+    floating IP assignment directly at Compute node level.</para>
+  </section>
+
+  <section id="lacp">
+    <title>Link Aggregation with LACP</title>
+
+    <para>Enea NFV Core 1.1 includes support for Link Aggregation Control
+    Protocol (LACP) (802.3ad) on data and control plane interfaces. I..e. -
+    specific Compute and Controller roles can now be assigned to network bonds
+    as well.</para>
+  </section>
+
+  <section id="post_dep">
+    <title>Post-Deploy Scripts for Provider Networks</title>
+
+    <para>This is a collection of scripts allowing the user to configure
+    OpenStack Provider Networks, which offer Layer-2 connectivity to instances
+    with optional support for DHCP and metadata services.</para>
   </section>
 </chapter>
\ No newline at end of file
diff --git a/book-enea-nfv-core-release-info/doc/new_in_this_release.xml b/book-enea-nfv-core-release-info/doc/new_in_this_release.xml
deleted file mode 100644
index 55b9735..0000000
--- a/book-enea-nfv-core-release-info/doc/new_in_this_release.xml
+++ /dev/null
@@ -1,12 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<chapter id="new_features">
-  <title>New In This Release</title>
-
-  <section>
-    <title>Mixed Arch Deployment</title>
-
-    <para>Mixed-arch Deployment: NFV Core 1.1 can be installed on a cluster
-    consisting of servers with mixed CPU architectures. The user can deploy
-    x86 Controllers and a combination of x86 and aarch64 Compute nodes.</para>
-  </section>
-</chapter>
\ No newline at end of file