2 files changed, 165 insertions, 23 deletions

diff --git a/doc/book-enea-nfv-access-release-info/doc/eltf_params_updated.xml b/doc/book-enea-nfv-access-release-info/doc/eltf_params_updated.xml
index 1a640a3..df317aa 100644
--- a/doc/book-enea-nfv-access-release-info/doc/eltf_params_updated.xml
+++ b/doc/book-enea-nfv-access-release-info/doc/eltf_params_updated.xml
@@ -42,7 +42,7 @@ export PATH=~/bin:$PATH</programlisting></para>
     correct also compared to the "previous" REL VER in pardoc-distro.xml
     "prev_baseline".</bridgehead>
 
-    <para id="EneaLinux_REL_VER"><phrase>2.2.1</phrase></para>
+    <para id="EneaLinux_REL_VER"><phrase>2.2.2</phrase></para>
 
     <para id="Yocto_VER"><phrase>2.4</phrase></para>
 
diff --git a/doc/book-enea-nfv-access-release-info/doc/known_bugs_and_limitations.xml b/doc/book-enea-nfv-access-release-info/doc/known_bugs_and_limitations.xml
index e2d338e..a218432 100644
--- a/doc/book-enea-nfv-access-release-info/doc/known_bugs_and_limitations.xml
+++ b/doc/book-enea-nfv-access-release-info/doc/known_bugs_and_limitations.xml
@@ -10,7 +10,8 @@
   <para><remark>The section further down is generated from JIRA with
   gen_known_issues.py, but that script is HARDCODED with affectedversion
   "EL7_3-virtualization" and needs to be adapted when a release info for
-  another ENFV Access version changes.</remark></para>
+  another ENFV Access version changes.</remark><emphasis
+  role="bold">Product-specific Issues and Limitations</emphasis></para>
 
   <itemizedlist>
     <para><emphasis role="bold">Enea uCPE Manager</emphasis></para>
@@ -27,36 +28,60 @@
     </listitem>
 
     <listitem>
-      <para><remark>ELEMCR-1690</remark>There is no keep-alive mechanism in
-      place for the Device Call Home Connection.</para>
+      <para><remark>ELCCR-319</remark>After a successful installation or
+      upgrade, it takes about 2 minutes until the device is accessible from
+      the browser.</para>
     </listitem>
 
     <listitem>
-      <para><remark>LXCR-9274</remark>The Call Home functionality does not support
-       having multiple interfaces/routes that go from the device to the
-       uCPE Manager. The IP/DNS address might need to be changed to the
-       established socket IP.</para>
+      <para><remark>ELCCR-349</remark>After uninstalling the uCPE manager
+      using the <filename>uninstall.sh</filename> script, the
+      <literal>ec_postgres</literal> service remains in an abnormal state. If
+      a product has not been successfully installed originally or if the
+      installed resources (files, users, services, databases, environment
+      variables, etc.) have been manually changed/removed, the uninstall may
+      fail and some resources will not be removed from the machine. Reverting
+      resources in the case of a failed uninstall is not implemented.</para>
     </listitem>
 
     <listitem>
-      <para><remark>ELCCR-256</remark>The uCPE Manager cannot manage VNFs which
-      contain special characters in their name.</para>
+      <para><remark>ELCCR-371</remark>A software image for NFV Access runs
+      only upon the hardware platform it is built for. Currently, NFV Access
+      supports two separate platforms: Intel atom-c and Intel xeon-d. The user
+      uploading a software image to the uCPE Manager can specify which
+      platform the image belongs to. When upgrading devices that have older
+      versions of NFV Access (2.2.1 and earlier), the device does not provide
+      information about its platform. In such cases, it is not possible to
+      validate if it is acceptable to use a given software image for an
+      upgrade. In more recent versions of NFV Access (2.2.2 onwards), the
+      device supplies its platform and while upgrading a device, the system
+      will validate that the software image being upgraded to is of the same
+      platform type as the device.</para>
     </listitem>
 
     <listitem>
-      <para><remark>LXCR-9513</remark>When using In-Band Management on standard
-      interfaces (DPDK disabled), stopping and restarting a VNF is not supported.
-      To perform a VNF restart, it has to be deleted and reinstantiated.</para>
+      <para><remark>LXCR-9088</remark>Automation Framework and Test Harness
+      tests require python version 2.7.X. Please make sure it is installed
+      before using the framework.</para>
     </listitem>
 
     <listitem>
-      <para><remark>ELCCR-276</remark>The uCPE Manager does not prevent a user 
-        from creating multiple <literal>communication</literal> bridges assigned 
-        to the same physical port. Although this is an invalid configuration and 
-        OVS itself will not accept it, the configuration screens will incorrectly 
-        show that such a configuration is in effect. The user should take care 
-        while assigning a physical port to a communications bridge to ensure that 
-        the port being assigned has not already been assigned to another bridge.</para>
+      <para><remark>LXCR-????</remark>The Call Home functionality does not
+      support having multiple interfaces/routes that go from the device to the
+      uCPE Manager. The IP/DNS address might need to be changed to the
+      established socket IP.</para>
+    </listitem>
+
+    <listitem>
+      <para><remark>LXCR-9703</remark>Cannot delete a VNF using a bridge with
+      flows defined.</para>
+    </listitem>
+
+    <listitem>
+      <para><remark>LXCR-9799</remark>In case two HDDs installed with NFV
+      Access are attached to the same device, it is possible that NFV Access
+      will boot from the wrong partition. Please avoid having two NFV Access
+      images installed on two HDDs on the same device.</para>
     </listitem>
   </itemizedlist>
 
@@ -65,8 +90,10 @@
   "EL7_3-virtualization" and needs to be adapted when a release info for
   another ENFV Access version changes.</remark></para>
 
-  <itemizedlist condition="hidden">
-    <listitem>
+  <para><emphasis role="bold">General Issues and Limitations</emphasis></para>
+
+  <itemizedlist>
+    <listitem condition="hidden">
       <para><emphasis role="bold">PDF navigation</emphasis>: When using links
       to open other PDFs, or jump to another place in the same PDF, jumping
       back sometimes fails. This has been observed when opening a PDF in Adobe
@@ -74,10 +101,125 @@
       configured to open PDF files in an external PDF reader. As a workaround,
       open the HTML version of the document.<remark>LXCR-3283</remark></para>
     </listitem>
+
+    <listitem>
+      <para><remark>LXCR-9773</remark>REST API changes for specified modules
+      that might cause backward compatibility issues, are listed below:</para>
+
+      <itemizedlist>
+        <listitem>
+          <para>CustomScripts:</para>
+
+          <para>The <literal>uploadCustomScript()</literal> method takes in an
+          additional argument (device module name). This should not affect
+          current REST clients, since CustomScript functionality is available
+          only for NFV Access 2.2.2.</para>
+        </listitem>
+
+        <listitem>
+          <para>Device Upgrade:</para>
+
+          <para>A new method <literal>-- upload() --</literal> has been added
+          to allow uploads of NFV Access software images to the uCPE Manager.
+          This should not affect current REST clients, since it is a new
+          method.</para>
+        </listitem>
+
+        <listitem>
+          <para>VnfManager:</para>
+
+          <para>A new method <literal>-- upload() --</literal> has been added
+          to allow uploads of VNF images to the uCPE Manager as part of the
+          onboarding process. This should not affect current REST clients,
+          since it is a new method.</para>
+        </listitem>
+
+        <listitem>
+          <para>VcpeAgent (i.e. NFV Access device module):<itemizedlist>
+              <listitem>
+                <para>The system-attributes config table was split into
+                system-attributes-state (operational data) and
+                system-attributes (configuration data).<itemizedlist>
+                    <listitem>
+                      <para>The configuration data still contains the
+                      attributes: device-name, device-description and
+                      initial-configuration-complete.</para>
+                    </listitem>
+
+                    <listitem>
+                      <para>The fields device-type, device-version, device-id,
+                      device-latitude, and device-longitude are now
+                      operational data. device-ip-address has been added as
+                      oper data.</para>
+                    </listitem>
+
+                    <listitem>
+                      <para>customer-tag in release version 2.2.1 was a config
+                      leaf-list, it is now a leaf called device-customer-tags
+                      (comma-separated).</para>
+                    </listitem>
+
+                    <listitem>
+                      <para>mgmt-ip-address has been added as oper data. This
+                      attribute was configured within an ovs-bridge of type
+                      inband-mgmt.</para>
+                    </listitem>
+                  </itemizedlist></para>
+              </listitem>
+
+              <listitem>
+                <para>The external-interface-capabilities operational table
+                now has "wan" and "mgmt" Booleans.</para>
+              </listitem>
+
+              <listitem>
+                <para>The external-interface configuration table now has a
+                choice of "wan".</para>
+
+                <para>New fields for this type are mgmt-interface,
+                address-assignment , ip-address, gateway, netmask (only
+                considered if static).</para>
+              </listitem>
+
+              <listitem>
+                <para>In ovs-bridge, for the choice of inband-mgmt, the
+                mgmt-address and mgmt-port fields have been removed (there are
+                no fields left in this choice).</para>
+              </listitem>
+
+              <listitem>
+                <para>In the Host operational table, there are a couple of
+                changes:<itemizedlist>
+                    <listitem>
+                      <para>The "name" field has been removed, there is still
+                      a "host-name" field.</para>
+                    </listitem>
+
+                    <listitem>
+                      <para>A "machine-type" field has been added.</para>
+                    </listitem>
+                  </itemizedlist></para>
+              </listitem>
+            </itemizedlist></para>
+        </listitem>
+      </itemizedlist>
+    </listitem>
+
+    <listitem>
+      <para>REST clients should see some minor changes depending upon whether
+      they are dealing with version 2.2.1 or 2.2.2 of the device. Code that
+      deals with the system-attributes table, in-band management OVS bridges,
+      or the host operational data might need to be modified.</para>
+
+      <para>The new wan interface type only matters in that you need a
+      wan-mgmt interface configured to create the in-band mgmt. bridge. This
+      should typically happen automatically as part of initial install or
+      upgrade and should not affect the REST clients</para>
+    </listitem>
   </itemizedlist>
 
   <!-- The file with a section below is autocreated by make init  -->
 
   <!-- <xi:include href="jiraissues_generated.xml"
               xmlns:xi="http://www.w3.org/2001/XInclude" /> -->
-</chapter>
+</chapter>
\ No newline at end of file