#49827 Ticket 48818 - For a replica bindDNGroup, should be fetched the first time it is used not when the replica is started
Closed by spichugi. Opened by tbordaz.
tbordaz/389-ds-base Ticket-49818  into  master

Download 49827.patch

Bug Description:
The fetching of the bindDNGroup is working as designed but this ticket is to make it more flexible

At startup, if the group does not contain the replica_mgr.
No replication session will succeed until bindDnGroupCheckInterval delay.
updatedn_group_last_check is the timestamp of the last fetch. At startup
updatedn_group_last_check is set to the current time. So the next fetch will happen not before
updatedn_group_last_check+bindDnGroupCheckInterval.
If the groupDn is changed after startup, no incoming replication can happen for the first
bindDnGroupCheckInterval seconds

Fix Description:
The fix consist to unset updatedn_group_last_check so that the group will be fetch when the first
incoming replication session will happen.

https://pagure.io/389-ds-base/issue/49818

Reviewed by: ?

Platforms tested: F27

Flag Day: no

Doc impact: no

C code looks good , ack. But I think QE wants new tests to go into the suites (replication suite in this case). I think they want to get rid of the "tickets" altogether.

@mreynolds thanks for the review I will move the test to the replication suite.

@lkrispen the fix works with freeipa 4.6 and 389-ds 1.3.8.4

The same as for the previous test case in PR#49790.
Could you please change test_ticket49818, Specify a test case purpose or name here and :id: 0?

We shouldn't use the old AgreementLegacy object for pausing replication. More info can be found here - https://fedorapeople.org/~spichugi/html/cheatsheet.html

In your case, the most efficient way to pause the replication is like this:

topo.pause_all_replicas()
topo.resume_all_replicas()

The same is here, it is AgreementLegacy object that will be deprecated one day. Instead, you can do like this (the same as you've done with Replicas):

agmts = Agreements(M1)
agmt = agmts.list()[0]
agmt.replace_many(('nsDS5ReplicaBindDN', test_user.dn),
                                    ('nsds5ReplicaCredentials', PASSWD))

@spichugi thanks for the tips.
Something not clear about the agreements. Agreements(M1) gives access to all agreements defined on M1. In my case there is only one agreement so agmts.list()[0] will find it, but if there are many of them how can I retrieve the exact agreement I would like to update ?

rebased onto 1e3a19f0c75a4eadb8354bc4970a2149abc5a570

@spichugi thanks for the tips.
Something not clear about the agreements. Agreements(M1) gives access to all agreements defined on M1. In my case there is only one agreement so agmts.list()[0] will find it, but if there are many of them how can I retrieve the exact agreement I would like to update ?

Right, in your case it is enough.
And if you want to get the exact agreement, you can point it out by its name (which is the last three numbers of the other instance's port).

agmts = Agreements(M1)
agmt_to_2 = agmts.get(str(M2.port)[-3:])

Though I think it is a bit too much. I'll add an additional option that will accept DirSrv object of the other instance. Like:

agmts = Agreements(M1)
agmt_to_2 = agmts.get(to_instance=M2)

What do you think?

I prefer the additional option ;), but could it be extended to something like

agmt = agmts.get(to_instance=M2_host, to_port=M2_port)

@spichugi, regarding the testcase in the patch, is it okay for you ? (@mreynolds already gave his ack regarding the change in the server)

I prefer the additional option ;), but could it be extended to something like
agmt = agmts.get(to_instance=M2_host, to_port=M2_port)

Okay, makes sense. If we create some special agreement, not the one for the DirSrv instance's host and port, we'd like to get this exact agreement.

Thank you! And you have my ack. I've just tested it.

rebased onto 4206d278118c25ef0816dc1df1b735ad32c3ed66

Pull-Request has been merged by tbordaz

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 pull request has been cloned to Github as issue and is available here:
- https://github.com/389ds/389-ds-base/issues/2886

If you want to continue to work on the PR, please navigate to the github issue,
download the patch from the attachments and file a new pull request.

Thank you for understanding. We apologize for all inconvenience.

Pull-Request has been closed by spichugi

Metadata