What happened at customer site is:
two nodes in replication, in sync
MODRDN of same rdn (cn=x) from ou=z,dc=com to new superior ou=y,dc=com in node 02.
In node 01, the MODRDN fails with err=1.
After checking, in node 01:
cn=x,ou=z,dc=com cn=x,ou=y,dc=com
are both present.
Metadata Update from @lkrispen: - Custom field component adjusted to None - Custom field origin adjusted to None - Custom field reviewstatus adjusted to None - Custom field rhbz adjusted to https://pagure.io/389-ds-base/issue/49431 - Custom field type adjusted to None - Custom field version adjusted to None
Metadata Update from @lkrispen: - Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1506831 (was: https://pagure.io/389-ds-base/issue/49431)
<img alt="0001-Ticket-49431-replicated-MODRDN-fails-breaking-replic.patch" src="/389-ds-base/issue/raw/files/20a14477469be8ef77d92d1023456c6d8409d1c8e966837759293e11a47643de-0001-Ticket-49431-replicated-MODRDN-fails-breaking-replic.patch" />
Metadata Update from @lkrispen: - Custom field reviewstatus adjusted to review (was: None)
Looks good. Ack, but what branch is this patch based off of? I see a lot of tabs in urp.c that should not be there in master branch.
Metadata Update from @mreynolds: - Custom field reviewstatus adjusted to ack (was: review)
as I said in the review request, this patch applies only to 1.3.6 - master has the new conflict code
Looks good. Ack, but what branch is this patch based off of? I see a lot of tabs in urp.c that should not be there in master branch. as I said in the review request, this patch applies only to 1.3.6 - master has the new conflict code
Sorry I did not read the review request email. However, there was no mention of this in the patch or the ticket.
committed to 1.3.6
009800b..7cbeed8 389-ds-base-1.3.6 -> 389-ds-base-1.3.6
Metadata Update from @mreynolds: - Issue close_status updated to: fixed - Issue set to the milestone: 1.3.6.0 - Issue status updated to: Closed (was: Open)
<img alt="0001-Ticket-49431-Add-CI-test-case.patch" src="/389-ds-base/issue/raw/files/66d1a2a00677119eed6f6d997b41c18a0030d0518412b627bc75180e6874d00b-0001-Ticket-49431-Add-CI-test-case.patch" />
I don't see how you verify that replication is working in both directions
I think what @lkrispen is saying is you need to validate that tuser_A and tuser_B have the correct new rdn on both masters, not just one.
no, what I am saying is that after the modrdns have been applied and repliciated, we need to verify that new updates are replicated in both directions. The bug is not in the modrn themselves, but that they stopped replication in one direction when a conflict was created
Ahh thanks for the clarification :)
<img alt="0001-Ticket-49431-Add-CI-test-case.patch" src="/389-ds-base/issue/raw/files/68441e6f27a885bf8ea53c41bb9f61daeabdaacfa82cc20891ad9573443e87b3-0001-Ticket-49431-Add-CI-test-case.patch" />
Yes I believe this test works with @lkrispen 's concerns met. Thanks! @lkrispen do you agree?
yes
@spichugi @firstyear if everything looks fine, can we please merge it. Thanks.
commit ca855b8 Author: Amita Sharma amsharma@redhat.com Date: Mon Dec 11 19:29:37 2017 +0530
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/2490
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: fixed)
Login to comment on this ticket.