Bug #5450

When importing a slave with higher UID/GID than master, quotas entries prevent synchronization from occuring

Added by Roy Keene over 3 years ago. Updated over 3 years ago.

Status:ClosedStart date:10/10/2017
Priority:NormalDue date:
Assignee:Juan Jose Montiel Cano% Done:

0%

Category:Core & System
Target version:Release 5.4.3
Resolution:worksforme Pull request:
Affected Versions:OpenNebula 5.4

Description

In OpenNebula 5.4.1 if you try to import a slave that had a higher GID or UID than the
master's highest UID/GID then when the synchronization occurs the INSERT will fail
with a primary key violation (when trying to create a new group):

Tue Oct 10 15:14:34 2017 [Z100][ONE][E]: SQL command was: INSERT INTO group_quotas (group_oid, body) VALUES  (102,'<QUOTAS><ID>102</ID><DATASTORE_QUOTA></DATASTORE_QUOTA><NETWORK_QUOTA></NETWORK_QUOTA><VM_QUOTA></VM_QUOTA><IMAGE_QUOTA></IMAGE_QUOTA></QUOTAS>'), error 1062 : Duplicate entry '102' for key 'PRIMARY'
Tue Oct 10 15:14:34 2017 [Z100][ReM][I]: Error replicating log entry 206 in zone

Setup conditions:

MASTER
------

# onegroup create dev
# onegroup create ten01

SLAVE
-----

# onegroup create ops
# onegroup create ten0
# onegroup delete ten0
# onegroup create ten01

Setup federation between master and slave

Then create a new group, which will be group ID #102

Replication to slave will fail because the slave already has an entry in "group_quotas" regarding group ID #102, left over from before the federation

Possible solutions:
1. Use "INSERT OR REPLACE" for synchronization to replace the invalid data
2. Delete the "group_quotas" (and likely "user_quotas") data when importing slaves

opennebula-5.4.1-fixfederationimport.diff Magnifier (2.2 KB) Roy Keene, 10/11/2017 04:10 PM


Related issues

Related to Feature #5514: Include a procedure to automatically import zone resource... New 10/27/2017

History

#1 Updated by Roy Keene over 3 years ago

Attached is a patch I am using.

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

  • Target version set to Release 5.4.3

#3 Updated by Ruben S. Montero over 3 years ago

  • Assignee set to Juan Jose Montiel Cano

#4 Updated by Juan Jose Montiel Cano over 3 years ago

Hello. I'm trying to reproduce this bug but I can't reproduce it, did you delete all users and groups in slave zone? you need to recreate all users and groups into master zone.

You can view a guide about this here: http://docs.opennebula.org/5.4/advanced_components/data_center_federation/federationconfig.html#importing-existing-opennebula-zones

Thanks!

#5 Updated by Ruben S. Montero over 3 years ago

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

#6 Updated by Ruben S. Montero over 3 years ago

  • Related to Feature #5514: Include a procedure to automatically import zone resources into a federation added

#7 Updated by Roy Keene over 3 years ago

I followed the procedure as documented. The issue is that when you import the master data into the slave it replaces the USER and GROUP tables on the slave from the master, but does not clear the USER_QUOTAS or GROUP_QUOTAS tables, so they refer to user and group IDs that no longer mean anything, and further if you then try to create a new user/group on the master it will try to create the corresponding blank quota entry on the slave and fail, since the OID key is already present.

It is 100% reproducible in OpenNebula 5.4.1 and I can provide a demo if requested.

Also available in: Atom PDF