[389-devel] Advice on a problem (syncrepl + entryuuid)
Hi all,
I've been a bit stuck on this problem, and I was hoping for some advice or thoughts.
So, part of the migration from openldap, and in general, is that we support entryuuid.
That's all fine. I made a decision to allow entryuuid to diverge from nsuniqueid, as
entryuuid is often a primary key in many databases. So we should be able to bring in
entryuuids' that already exist.
This creates a dilema in syncrepl though. Syncrepl currently uses the nsuniqueid in place
of the entryuuid for sync. It does not appear to be straight forward to change this to use
entryuuid if it exists - when we send a delete, that comes from the retro changelog, and
it stores a delete as a delete with the nsuniqueid. That also means the entry that held
the nsunique in question may no longer exist so we cant reference what the entryuuid was.
So this leads me to a problem of "how to solve it".
I still think allowing entryuuid to diverge from nsuniqueid is the right call. It opens
more scenarioes up to us for migration.
So some options:
* EntryUUID has to be consistent to nsuniqueid, and when we see a create with an
entryUuid, we assign the nsunique from the entryuuid we have rather than generating it. If
there is no entryuuid, we generate it from the nsuniqueid.
* Extend the retrochangelog to store the entryuuid as well as the nsunique for
deletes/mods/adds.
* Have syncrepl "strip" entryuuid, so that the inconsistent attribute is never
sent to clients (but this means that entryuuid between 389 -> syncrepl client diverges,
which could have other consequences).
* Rather than send the set of deletes, we can send a list of 'what uuids are still
present' that implies all others are removed. It's less efficient on the wire, but
it works around the problem. (More risk of breaking IPA parts though).
* Disallow entryuuid and syncrepl plugins at the same time - you have one or the other
(probably good for IPA tbh).
* Other thoughts?
I'm honestly not sure whats the best choice - they are all tradeoffs in some way or
another, with their own risks. So I'd appreciate your advice here.
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs