From acb3384a8e42c7de1b35029055110b916af0ce51 Mon Sep 17 00:00:00 2001 From: mrpa Date: Tue, 21 Apr 2020 18:46:02 +0200 Subject: Modified content in: book-enea-nfv-access-cmc-example-usecases book-enea-nfv-access-getting-started book-enea-nfv-access-open-source book-enea-nfv-access-release-info book-enea-nfv-access-system-test-specification. Change-Id: I1f17c4d484e25d1b94a9fb5cd28b3d02f246a40c Signed-off-by: mrpa --- .../doc/known_bugs_and_limitations.xml | 225 +++++---------------- 1 file changed, 52 insertions(+), 173 deletions(-) (limited to 'doc/book-enea-nfv-access-release-info/doc/known_bugs_and_limitations.xml') 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 961a281..ce9e9e0 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 @@ -4,100 +4,94 @@ Known Issues and Limitations in this Release - This chapter lists the known issues that affect the current - release. + This chapter lists the known general issues and limitations that + affect the current release. 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.Product-specific Issues and Limitations + another ENFV Access version changes. - Enea uCPE Manager - - ELCCR-99The uCPE Manager fails to onboard renamed - VNF bundles downloaded to the same repo. + ELCCR-119Multiple uCPE devices behind a firewall + or a gateway connecting with Call-Home are not supported. - ELCCR-119No support is provided for multiple uCPE - devices behind a firewall or gateway connecting Call Home to the uCPE - Manager (running outside the local network). + ELCCR-319After a successful installation or + upgrade, it takes about 2 minutes until the device is accessible from + the uCPE Manager. - ELCCR-319After a successful installation or - upgrade, it takes about 2 minutes until the device is accessible from - the browser. + ELCCR-349If the uCPE Manager has not been + successfully installed originally or if the installed resources (files, + users, services, databases, environment variables, etc.) have been + manually changed/removed, the uninstallation may fail and some resources will + have to be removed manually. + + + + ELCCR-349Recovery in case of a failed uCPE Manager + uninstallation is not implemented. In case of a failure the resources have to + be removed manually. - 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-454Only the default database is supported, + any requests for alternative databases are custom adaptations not tested + by Enea. - - ELCCR-454Only the default database is supported, any requests for alternative databases are custom adaptations. - 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. + ELCCR-474Deleting VNF instances with flows + configured on the OVS bridges can be done only after removing the + flows. - + - ELCCR-474In case one VNF has configured flows in - one of the OVS bridges it is connected to, the VNF instance cannot be - deleted before removing the appropriate flows. + ELCCR-527Cancelling a file upload in the uCPE + Manager will require the user to close and reopen the upload window for + the next upload to work. - - ELCCR-527When uploading a file, if the user cancels the upload, the upload window must be closed and reopened in order for the next upload to work. - LXCR-9088Automation Framework and Test Harness - tests require python version 2.7.X. Please make sure it is installed - before using the framework. + ELCCR-572Sometimes when selecting and deleting + more than one VNF instance simultaneously, an error message might be + triggered, even if the delete operation succeeds. 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. + uCPE Manager. - 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. + LXCR-9799NFV Access can boot from the wrong + partition if two HDDs are attached to the same device, this must be + avoided. - - 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. + + LXCR-9853The WAN interface of uCPE device needs + to be connected to a network with at least a router/gateway installed + for next-hop communication. + + + + LXCR-9853When configuring a VNF with WAN and + Management access on different interfaces, the user has to ensure VNF's + virtual interfaces are configured so that proper routes are used for + traffic egress-ing the VNF. + - General Issues and Limitations + + LXCR-9904NFV Access cannot be installed on USB + storage devices. + - PDF navigation: When using links to open other PDFs, or jump to another place in the same PDF, jumping @@ -106,121 +100,6 @@ 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 - -- cgit v1.2.3-54-g00ecf