Bug 1283489 - ERROR: duplicate key value when calling setupNetworks
Summary: ERROR: duplicate key value when calling setupNetworks
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.6.9
Hardware: x86_64
OS: Linux
urgent
urgent
Target Milestone: ovirt-3.6.z-async
: ---
Assignee: Alona Kaplan
QA Contact: Michael Burman
URL:
Whiteboard: network
Depends On:
Blocks: 1430513
TreeView+ depends on / blocked
 
Reported: 2015-11-19 06:56 UTC by Meni Yakove
Modified: 2021-05-01 16:44 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-09-14 18:32:30 UTC
oVirt Team: Network
Target Upstream Version:
Embargoed:
myakove: testing_plan_complete+


Attachments (Terms of Use)
engine logs (895.47 KB, application/x-bzip)
2015-11-19 06:56 UTC, Meni Yakove
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2017:2737 0 normal SHIPPED_LIVE Red Hat Enterprise Virtualization Manager 3.6.12 2017-09-14 22:32:16 UTC
oVirt gerrit 80840 0 ovirt-engine-3.6 MERGED engine: Expanding monitoring lock to the whole setup networks command 2020-12-13 08:03:55 UTC

Description Meni Yakove 2015-11-19 06:56:06 UTC
Created attachment 1096501 [details]
engine logs

Description of problem:
Sometimes when calling setupNetwork the operation fails with error:
CallableStatementCallback; SQL [{call insertnetworkattachment(?, ?, ?, ?, ?, ?, ?, ?)}]; ERROR: duplicate key value violates unique constraint "network_attachments_network_id_key"



Version-Release number of selected component (if applicable):
rhevm-3.6.0.3-0.1.el6.noarch


Steps to Reproduce:
1. Run tier1 network automation test


Additional info:
Correlation-Id: labels_create_9c0a7b3d-eeb5-4b0e (for engine.log)

Comment 1 Yaniv Kaul 2015-11-20 08:02:57 UTC
Meni - why is the severity high? What is the frequency and what is the scenario? Sometimes is not clear enough.

Comment 2 Meni Yakove 2015-11-25 10:13:37 UTC
lower the severity to low since it's happened only few time (about 2-3 times for about 500 setupNetworks)

Comment 3 Meni Yakove 2016-02-01 12:54:14 UTC
Not reproduced anymore.

Comment 6 Dan Kenigsberg 2017-08-15 10:36:12 UTC
We are trying to understand why the customer sees these exception.

However, it is important to note right now that when a freshly-built el7 node is added to a cluster with required networks it is *expected* to become non-operational. When a host is added, only the management network is attached to it by default. Further networks have to be attached explicitly via nics or label. If the cluster two which the host is added has multiple required networks, having the management network is not enough and the host becomes non-operational.

Comment 7 Alona Kaplan 2017-08-16 07:18:28 UTC
Looking at the attached log and the db dump in the SOS report I can see that the installation of the host failed due to a race.
The host was refreshed by the vdsManager during the run of HostSetupNetworkCommand.
This issue was fixed in patch https://gerrit.ovirt.org/#/c/59318/9 (bug https://bugzilla.redhat.com/1324479). The fix was introduced in 4.0.

Comment 8 Dan Kenigsberg 2017-08-16 07:40:01 UTC
Based on comment 7, I believe that it would be possible to backport the fix to 3.6, but it would not be fun.

How disruptive is this bug for the customer? Would they want to upgrade to a hot-fixed rhvm-3.6.12 in order to avoid it? Or can they keep a stiff upper lip until their VM compatibility level is 3.6, and they can upgrade to rhvm-4 ?

Comment 18 Michael Burman 2017-08-23 06:12:54 UTC
Why the target milestone is 4.2?

Comment 23 Michael Burman 2017-09-07 06:29:05 UTC
Verified on - 3.6.12-0.1.el6

Comment 24 Emma Heftman 2017-09-14 14:51:43 UTC
Hi

Comment 26 errata-xmlrpc 2017-09-14 18:32:30 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2017:2737


Note You need to log in before you can comment on or make changes to this bug.