Bug #4892

onedb upgrade fails due to inserting a duplicate key

Added by Nils Schröder over 4 years ago. Updated almost 4 years ago.

Status:ClosedStart date:11/03/2016
Priority:LowDue date:
Assignee:Javi Fontan% Done:

0%

Category:Core & System
Target version:Release 5.4
Resolution:wontfix Pull request:
Affected Versions:OpenNebula 4.8, OpenNebula 5.2

Description

Hello,
following the upgrade guide (http://docs.opennebula.org/5.2/intro_release_notes/upgrades/upgrade_48.html) I am trying to upgrade OpenNebula from version 4.8 to 5.2 on a Debian 8.6 machine.

Unfortunately I have some issues with the onedb upgrade command and I think this is a bug. At some point the onedb upgrade is trying to recreate some tables and is trying to insert duplicate primary keys into the newly created table. Please see the attached output of onedb upgrade command, I was not able to find an additional logfile.

I digged some deeper into it and here are my two cents:
The script /usr/lib/one/ruby/onedb/local/4.11.80_to_4.13.80.rb wants to recreate the database table vm_pool. Therefore it renames the table to old_vm_pool (line 92) and creates a new table vm_pool (line 93). Afterwards it inserts all done VMs into the new table, see line 95. Unfortunately in line 101 and following the script is trying to insert all lines from the old_vm_pool into vm_pool. But all VMs with state 6 are already there and so we get a duplicate key error. As far as I can see you must exclude all VMs with state 6 here. Interestingly the correct line is already in the script above the "wrong" line, but it is commented (line 100).

I quickfixed the error by commenting line 101 and uncommented line 100. But I am not into ruby and so I can not predict the impact of this change. And the fix was already there but not active so someone did this on purpose. But as it is it does not work. So should I skip line 95 and let all be done by line 101 or should I use line 95 in conjunction with line 100?

After I applied the quickfix a similiar issue with table history arises. Same script in lines 128:
First an "INSERT INTO history SELECT * FROM old_history WHERE etime<>0;"
Afterwards it is trying to insert all matching "SELECT * FROM old_history" and one line above there is (to my knowledge) the correct but commented line "SELECT * FROM old_history WHERE etime=0".

If you need any further informations please ask. I appreciate your help very much.

Thank you,
Nils Schröder

P.S.: For better understanding here a snipped from the script /usr/lib/one/ruby/onedb/local/4.11.80_to_4.13.80.rb:
line
92 @db.run "ALTER TABLE vm_pool RENAME TO old_vm_pool;"
93 @db.run "CREATE TABLE vm_pool (oid INTEGER PRIMARY KEY, name VARCHAR, body MEDIUMTEXT, uid INTEGER, gid INTEGER, last_poll INTEGER, state INTEGER, lcm_state INTEGER, owner_u INTE$

95 @db.run "INSERT INTO vm_pool SELECT * FROM old_vm_pool WHERE state=6;"

97 log_time()

99 @db.transaction do
100 ("SELECT * FROM old_vm_pool WHERE state<>6") do |row|
101 @db.fetch("SELECT * FROM old_vm_pool") do |row|
doc = Nokogiri::XML{|c| c.default_xml.noblanks}
update_monitoring(doc.root.at_xpath("/VM"))
@db[:vm_pool].insert(
:oid => row[:oid],
:name => row[:name],
:body => doc.root.to_s,
:uid => row[:uid],
:gid => row[:gid],
:last_poll => row[:last_poll],
:state => row[:state],
:lcm_state => row[:lcm_state],
:owner_u => row[:owner_u],
:group_u => row[:group_u],
:other_u => row[:other_u])
end
end
@db.run "DROP TABLE old_vm_pool;"

bugreport.txt Magnifier - output of onedb upgrade (5.15 KB) Nils Schröder, 11/03/2016 01:38 PM


Related issues

Related to Bug #4911: Fix several issues in the migration process from 5.0 to 5.2 Closed 11/10/2016

History

#1 Updated by Ruben S. Montero over 4 years ago

  • Target version changed from Release 5.2 to Release 5.4

#2 Updated by Ruben S. Montero over 4 years ago

  • Related to Bug #4911: Fix several issues in the migration process from 5.0 to 5.2 added

#3 Updated by Ruben S. Montero about 4 years ago

  • Assignee set to Javi Fontan

#4 Updated by Javi Fontan almost 4 years ago

  • Status changed from Pending to Closed
  • Resolution set to wontfix

I'm closing this as it affects OpenNebula 4.12. If more people gets the same problem we can reopen it.

Also available in: Atom PDF