This chapter lists the known issues 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 Enea uCPE Manager ELCCR-99The uCPE Manager fails to onboard renamed VNF bundles downloaded to the same repo. 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 browser. 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. 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-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-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. 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-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. 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. 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 Reader, inside a browser with PDF add-on, as well as when the browser is 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