When importing a slave with higher UID/GID than master, quotas entries prevent synchronization from occuring
|Assignee:||Juan Jose Montiel Cano||% Done:|
|Category:||Core & System|
|Target version:||Release 5.4.3|
|Affected Versions:||OpenNebula 5.4|
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
# onegroup create dev # onegroup create ten01
# 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
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
#4 Updated by Juan Jose Montiel Cano almost 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
#7 Updated by Roy Keene almost 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.