From 2f3895595ef6b37ac4cc011773fd39f0d087ea24 Mon Sep 17 00:00:00 2001 From: mrpa Date: Thu, 20 Feb 2020 16:30:43 +0100 Subject: Updated rel notes for v2.2.2 Known issues and limitations chapter is updated. Change-Id: Idc3fa545673d1f1356d2feb7892119440b67b53d --- .../doc/eltf_params_updated.xml | 2 +- .../doc/known_bugs_and_limitations.xml | 186 ++++++++++++++++++--- 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 correct also compared to the "previous" REL VER in pardoc-distro.xml "prev_baseline". - 2.2.1 + 2.2.2 2.4 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 @@ 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. + another ENFV Access version changes.Product-specific Issues and Limitations Enea uCPE Manager @@ -27,36 +28,60 @@ - ELEMCR-1690There is no keep-alive mechanism in - place for the Device Call Home Connection. + ELCCR-319After a successful installation or + upgrade, it takes about 2 minutes until the device is accessible from + the browser. - LXCR-9274The 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. + ELCCR-349After uninstalling the uCPE manager + using the uninstall.sh script, the + ec_postgres 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. - ELCCR-256The uCPE Manager cannot manage VNFs which - contain special characters in their name. + ELCCR-371A 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. - LXCR-9513When 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. + LXCR-9088Automation Framework and Test Harness + tests require python version 2.7.X. Please make sure it is installed + before using the framework. - ELCCR-276The uCPE Manager does not prevent a user - from creating multiple communication 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. + LXCR-????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. + + + + LXCR-9703Cannot delete a VNF using a bridge with + flows defined. + + + + LXCR-9799In 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. @@ -65,8 +90,10 @@ "EL7_3-virtualization" and needs to be adapted when a release info for another ENFV Access version changes. - - + General Issues and Limitations + + + PDF navigation: 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.LXCR-3283 + + + LXCR-9773REST API changes for specified modules + that might cause backward compatibility issues, are listed below: + + + + CustomScripts: + + The uploadCustomScript() 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. + + + + Device Upgrade: + + A new method -- upload() -- 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. + + + + VnfManager: + + A new method -- upload() -- 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. + + + + VcpeAgent (i.e. NFV Access device module): + + The system-attributes config table was split into + system-attributes-state (operational data) and + system-attributes (configuration data). + + The configuration data still contains the + attributes: device-name, device-description and + initial-configuration-complete. + + + + 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. + + + + customer-tag in release version 2.2.1 was a config + leaf-list, it is now a leaf called device-customer-tags + (comma-separated). + + + + mgmt-ip-address has been added as oper data. This + attribute was configured within an ovs-bridge of type + inband-mgmt. + + + + + + The external-interface-capabilities operational table + now has "wan" and "mgmt" Booleans. + + + + The external-interface configuration table now has a + choice of "wan". + + New fields for this type are mgmt-interface, + address-assignment , ip-address, gateway, netmask (only + considered if static). + + + + 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). + + + + In the Host operational table, there are a couple of + changes: + + The "name" field has been removed, there is still + a "host-name" field. + + + + A "machine-type" field has been added. + + + + + + + + + + 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. + + 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 + - + \ No newline at end of file -- cgit v1.2.3-54-g00ecf