summaryrefslogtreecommitdiffstats
path: root/book-enea-nfv-core-release-info/doc/known_bugs_and_limitations.xml
diff options
context:
space:
mode:
Diffstat (limited to 'book-enea-nfv-core-release-info/doc/known_bugs_and_limitations.xml')
-rw-r--r--book-enea-nfv-core-release-info/doc/known_bugs_and_limitations.xml356
1 files changed, 356 insertions, 0 deletions
diff --git a/book-enea-nfv-core-release-info/doc/known_bugs_and_limitations.xml b/book-enea-nfv-core-release-info/doc/known_bugs_and_limitations.xml
new file mode 100644
index 0000000..039fae9
--- /dev/null
+++ b/book-enea-nfv-core-release-info/doc/known_bugs_and_limitations.xml
@@ -0,0 +1,356 @@
1<?xml version="1.0" encoding="ISO-8859-1"?>
2<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
3"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
4<chapter id="bugs-limitations">
5 <title>Known Issues and Limitations</title>
6
7 <para>Problems and limitations relevant to the current release are detailed
8 in this chapter. Corrections to bugs detected by Enea are submitted
9 upstream, and remaining issues are listed below.<remark>INFO: The <emphasis
10 role="bold">Release-Specific Problems</emphasis> section further down is
11 generated from JIRA with gen_known_issues.py, but that script is HARDCODED
12 with affectedversion "Enea NFV 1.0" and needs to be adapted when a release
13 info for another ENFV version changes.</remark></para>
14
15 <section id="bugs-limitations-gen">
16 <title>Release Specific Issues</title>
17
18 <orderedlist>
19 <listitem>
20 <para>Security groups are not working correctly for ICMP traffic in
21 deployments with OpenDaylight.</para>
22
23 <itemizedlist>
24 <listitem>
25 <para>Description and Impact:</para>
26
27 <orderedlist>
28 <listitem>
29 <para>When OPNFV is deployed with OpenDaylight as an SDN
30 controller, the Security Groups rules pertaining to ICMP do
31 not work as expected. The OpenFlow rules describing the ICMP
32 rules are inconsistent, so VMs can be pinged even when this is
33 not desired.</para>
34 </listitem>
35
36 <listitem>
37 <para>This reproduces on aarch64. On x86 the security groups
38 work correctly.</para>
39 </listitem>
40 </orderedlist>
41 </listitem>
42
43 <listitem>
44 <para>Workaround: N/A.</para>
45 </listitem>
46 </itemizedlist>
47 </listitem>
48
49 <listitem>
50 <para>Virtual instances do not get IP from DHCP in SFC scenarios with
51 ODL</para>
52
53 <itemizedlist>
54 <listitem>
55 <para>Description and Impact:</para>
56
57 <orderedlist>
58 <listitem>
59 <para>After a fresh deploy of OPNFV with OpenDaylight and the
60 Service Function Chaining scenario configurations, instances
61 fail to get IP from DHCP, due to OpenDaylight
62 malfunctioning.</para>
63 </listitem>
64
65 <listitem>
66 <para>The SFC VNFs are not reachable via SSH for management
67 and configuration.</para>
68 </listitem>
69 </orderedlist>
70 </listitem>
71
72 <listitem>
73 <para>Workaround: Restarting OpenDaylight via
74 <literal>systemctl</literal> fixes the problem.</para>
75 </listitem>
76 </itemizedlist>
77 </listitem>
78
79 <listitem>
80 <para>Scale-in and Scale-out operations are not supported</para>
81
82 <itemizedlist>
83 <listitem>
84 <para>Description and Impact:</para>
85
86 <orderedlist>
87 <listitem>
88 <para>When adding or removing nodes via Fuel installer on an
89 OPNFV deployment that uses OpenDaylight, flows in
90 <filename>ovs</filename> tables on the existing and new nodes
91 are not updated properly. Similarly, OpenvSwitch ports
92 interfaces are not removed when deleting nodes.</para>
93 </listitem>
94
95 <listitem>
96 <para>As a consequence, when adding a compute node to an
97 existing OPNFV deployment, the instances running on the new
98 compute node cannot be reached by floating IP. Scale-out and
99 scale-in operations are flawed.</para>
100 </listitem>
101 </orderedlist>
102 </listitem>
103
104 <listitem>
105 <para>Workaround: The rules can be manually configured, but this
106 is not scalable.</para>
107 </listitem>
108 </itemizedlist>
109 </listitem>
110
111 <listitem>
112 <para>Hot-plugging network interfaces does not work in aarch64
113 guests</para>
114
115 <itemizedlist>
116 <listitem>
117 <para>Description and Impact:</para>
118
119 <orderedlist>
120 <listitem>
121 <para>When the user tries to hot-plug a network port to a
122 running instance, this fails due to virtio negotiation failure
123 between the host and guest. This happens when the VM is using
124 a Linux Kernel version prior to 4.10. Port addition or
125 deletion is not possible.</para>
126 </listitem>
127
128 <listitem>
129 <para>This reproduces on aarch64.</para>
130 </listitem>
131 </orderedlist>
132 </listitem>
133
134 <listitem>
135 <para>Workaround: The user needs to upgrade the guest Linux Kernel
136 to 4.10 or later. In case of port addition, the user also needs to
137 manually set the link up and trigger the
138 <literal>dhclient</literal> request.</para>
139 </listitem>
140 </itemizedlist>
141 </listitem>
142
143 <listitem>
144 <para>Fuel Healthcheck Configuration tests fail when default
145 credentials are used</para>
146
147 <itemizedlist>
148 <listitem>
149 <para>Description and Impact:</para>
150
151 <orderedlist>
152 <listitem>
153 <para>The Configuration tests from the Fuel Healthcheck fail
154 when the OPNFV cluster operates with the default credentials.
155 This has no impact on the overall cluster
156 functionality.</para>
157 </listitem>
158
159 <listitem>
160 <para>This is architecture independent.</para>
161 </listitem>
162 </orderedlist>
163 </listitem>
164
165 <listitem>
166 <para>Workaround: In order to make these 3 test cases pass, the
167 user needs to:</para>
168
169 <orderedlist>
170 <listitem>
171 <para>Change the credentials for the root user on the Fuel
172 Master node: after logging on as root on the master node,
173 issue command <command>passwd</command> and provide the new
174 password.</para>
175 </listitem>
176
177 <listitem>
178 <para>Change the default credentials for the OpenStack
179 cluster: in Fuel Dashboard, for an Environment, change
180 Settings|General|OpenStack Access &gt; Password to something
181 other than the default.</para>
182 </listitem>
183
184 <listitem>
185 <para>Change the default credentials for Keystone on the
186 master node: in Fuel Dashboard, click on the user avatar and
187 select <literal>Change Password</literal>. This should be done
188 before deploy or you will need to redeploy to have the changes
189 applied.</para>
190 </listitem>
191 </orderedlist>
192 </listitem>
193 </itemizedlist>
194 </listitem>
195
196 <listitem>
197 <para>Fuel Healthcheck Stack update test fails</para>
198
199 <itemizedlist>
200 <listitem>
201 <para>Description and Impact:</para>
202
203 <para>The Platform test case number 5 (Update stack) from the Fuel
204 Healthcheck fails. This has no impact on the overal cluster
205 functionality.</para>
206 </listitem>
207
208 <listitem>
209 <para>Workaround: N/A.</para>
210 </listitem>
211 </itemizedlist>
212 </listitem>
213
214 <listitem>
215 <para>Issue #1 with Openstack Resource Agents and Compute Fencing
216 functionality</para>
217
218 <itemizedlist>
219 <listitem>
220 <para>Description and Impact:</para>
221
222 <para>In an OPNFV deployment that uses Openstack Resource Agents,
223 the neutron-openvswitch-agent is killed by Pacemaker when booting,
224 due to Pacemaker misconfiguration.</para>
225 </listitem>
226
227 <listitem>
228 <para>Workaround:</para>
229
230 <para>Starting the <literal>systemd</literal> service manually
231 makes it run successfully. Enea NFV Core 1.0 will be shipped
232 without Openstack Resource Agents, therefore this issue should not
233 affect the user.</para>
234 </listitem>
235 </itemizedlist>
236 </listitem>
237
238 <listitem>
239 <para>Virtual instances are not affected by removing a node from Ceph
240 Storage Cluster</para>
241
242 <itemizedlist>
243 <listitem>
244 <para>Description and Impact:</para>
245
246 <para>Engineering wanted to validate the survival of the storage
247 systems when a single disk is removed without causing data loss.
248 Without physical access to the test setup, this test is not
249 feasible.</para>
250 </listitem>
251
252 <listitem>
253 <para>Workaround:</para>
254
255 <itemizedlist>
256 <listitem>
257 <para>The chosen approach was to validate what happens to the
258 Ceph cluster when network connectivity is lost for the Storage
259 interface of one of the nodes. The observed behavior: no
260 impact on a running instance using Ceph for volume
261 storage.</para>
262 </listitem>
263
264 <listitem>
265 <para><ulink
266 url="http://ceph.com/geen-categorie/admin-guide-replacing-a-failed-disk-in-a-ceph-cluster/">Reference
267 information</ulink></para>
268 </listitem>
269 </itemizedlist>
270 </listitem>
271 </itemizedlist>
272 </listitem>
273
274 <listitem>
275 <para>Issue #2 with Openstack Resource Agents and Compute Fencing
276 functionality</para>
277
278 <itemizedlist>
279 <listitem>
280 <para>Description and Impact:</para>
281
282 <para>In an OPNFV deployment that uses Openstack Resource Agents,
283 when we configure the <literal>fence_compute</literal> as a
284 Pacemaker resource, the Controller nodes start to reboot each
285 other endlessly.</para>
286 </listitem>
287
288 <listitem>
289 <para>Workaround:</para>
290
291 <para>Enea NFV Core 1.0 will be shipped without Openstack Resource
292 Agents, therefore this issue should not affect the user.</para>
293 </listitem>
294 </itemizedlist>
295 </listitem>
296
297 <listitem>
298 <para>Offline Deploy with Fuel fails at times</para>
299
300 <itemizedlist>
301 <listitem>
302 <para>Description and Impact:</para>
303
304 <para>The Postfix installation and post-install configuration
305 sometimes take longer when the Fuel deployment is performed
306 without Internet connectivity. The <emphasis
307 role="bold">tools</emphasis> Puppet task has a 5 minute completion
308 timeout, causing there to not be enough time left for the other
309 components of the tools task to be executed.</para>
310 </listitem>
311
312 <listitem>
313 <para>Workaround:</para>
314
315 <para>Simply press <literal>Deploy changes</literal> again. Since
316 by now Postfix is installed, it will skip the installation and
317 finish in time.</para>
318 </listitem>
319 </itemizedlist>
320 </listitem>
321 </orderedlist>
322 </section>
323
324 <section condition="hidden" id="bugs-limitations-doc">
325 <title>Documentation</title>
326
327 <itemizedlist spacing="compact">
328 <listitem>
329 <para><emphasis role="bold">PDF navigation</emphasis>: When using
330 links to open other PDFs, or jump to another place in the same PDF,
331 jumping back sometimes fails. This has been observed when opening a
332 PDF in Adobe Reader, inside a browser with PDF add-on, as well as when
333 the browser is configured to open PDF files in an external PDF reader.
334 As a workaround, open the HTML version of the
335 document.<remark>LXCR-3283</remark></para>
336 </listitem>
337 </itemizedlist>
338 </section>
339
340 <section condition="hidden" id="bugs-limitations-other">
341 <title>Miscellaneous</title>
342
343 <itemizedlist spacing="compact">
344 <listitem>
345 <para></para>
346
347 <remark>list all misc problems here.</remark>
348 </listitem>
349 </itemizedlist>
350 </section>
351
352 <!-- The file with a section below is autocreated by make init
353
354 <xi:include href="jiraissues_generated.xml"
355 xmlns:xi="http://www.w3.org/2001/XInclude" /> -->
356</chapter> \ No newline at end of file
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-06-19 00:24:45 +0000