Hi William,
I think this case is covered in IPA. I have never seen a new replica added
with the same former ID of an old one.
The former ruvs are not cleaned automatically, though, in current versions
and it's not a very severe issue now. There are also ipa commands to list
and clean the ruvs.
I have also heard or read that in the dev versions (not still delivered),
the cleaning is automatic, as you are proposing.
Thanks a lot.
regards,
German.
On Mon, Jun 13, 2016 at 7:21 AM, William Brown <wibrown(a)redhat.com> wrote:
Hi,
I was discussing with some staff here in BNE about replication.
It seems a common case is that admins with 2 or 3 servers in MMR (both DS
and IPA) will do this:
* Setup all three masters A, B, C (replica id 1,2,3 respectively)
* Run them for a while in replication
* Remove C from replication
* Delete data, change the system
* Re-add C with the same replica id.
Supposedly this can cause duplicate RUV entries for id 3 in masters A and
B. Of course, this means that replication has all
kinds of insane issues at this point ....
On one hand, this is the admins fault. But on the other, we should handle
this. Consider an admin who re-uses an IPA replica
setup file, without running CLEANALLRUV
So, an have some idea for this. Any change to a replication agreement,
should trigger a CLEANALLRUV, before we start the
agreement. This means on our local master we have removed the bad RUV
first, then we can add the RUV of the newly added master
when needed ....
What do you think? I think that we must handle this better, and it should
be a non-issue to admins.
We can't prevent an admin from intentionally adding duplicate ID's to the
topology though. So making it so that the ID's are not
admin controlled would prevent this, but I haven't any good ideas about
this (yet)
--
Sincerely,
William Brown
Software Engineer
Red Hat, Brisbane
--
389-devel mailing list
389-devel(a)lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject...