1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
|
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<chapter id="bugs-limitations">
<title>Known Issues and Limitations in this Release</title>
<para>This chapter lists the known issues that affect the current
release.</para>
<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><emphasis
role="bold">Product-specific Issues and Limitations</emphasis></para>
<itemizedlist>
<para><emphasis role="bold">Enea uCPE Manager</emphasis></para>
<listitem>
<para><remark>ELCCR-99</remark>The uCPE Manager fails to onboard renamed
VNF bundles downloaded to the same repo.</para>
</listitem>
<listitem>
<para><remark>ELCCR-119</remark>No support is provided for multiple uCPE
devices behind a firewall or gateway connecting Call Home to the uCPE
Manager (running outside the local network).</para>
</listitem>
<listitem>
<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>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><remark>ELCCR-454</remark>Only the default database is supported, any requests for alternative databases are custom adaptations.</listitem>
<listitem>
<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>ELCCR-474</remark>In 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.</para>
</listitem>
<listitem><remark>ELCCR-527</remark>When 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.</listitem>
<listitem>
<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>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-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>
<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>
<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
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.<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>
|
