Bug #5450
When importing a slave with higher UID/GID than master, quotas entries prevent synchronization from occuring
| Status: | Closed | Start date: | 10/10/2017 | |
|---|---|---|---|---|
| Priority: | Normal | Due 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
Related issues
History
#1
Updated by Roy Keene over 3 years ago
- File opennebula-5.4.1-fixfederationimport.diff
added
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.