When a replica is created and the replica can be updated by members of nsDS5ReplicaBindDnGroup, the attribute nsDS5ReplicaBindDNGroupCheckInterval is used to fetch the members if the group changes. By default, nsDS5ReplicaBindDNGroupCheckInterval=-1. That means never refresh that can create confusion if the group is changed later.
Since 1.3.5
nsDS5ReplicaBindDNGroupCheckInterval=-1
nsDS5ReplicaBindDNGroupCheckInterval=3 fetch at next bind 3s later. nsDS5ReplicaBindDNGroupCheckInterval=0 fetch at each bind
Metadata Update from @mreynolds: - Custom field component adjusted to None - Custom field origin adjusted to None - Custom field reviewstatus adjusted to None - Custom field type adjusted to None - Custom field version adjusted to None - Issue set to the milestone: 1.3.8
Simon will start with this
Metadata Update from @spichugi: - Issue assigned to spichugi
Is this still an issue?
Metadata Update from @mreynolds: - Issue set to the milestone: 1.4 backlog (was: 1.3.8)
I think that -1 is not the ideal default value, but it is a definite behaviour: never check for groupupdates, which inmany cases is good enough.
Changing the default rises the question on what to set it: 0 would mean always check, this would gave a lot of impact since groups have to be evaluated for each repl session
and setting it to "a number" could be also confusing or bad for some applications.
So I tend to keep it as it is, but wait for @tbordaz response
I think the current behavior is bad. I agree that most of the time, never check the groupupdates, is good enough but when for some reason the group gets updated it will result with long investigations both from customer or/and support.
freeipa uses 2sec delay during deployments then 60s during normal production. So even when the topology is stable freeipa prefers periodic useless check than taking the risk to investigate a failure.
I agree that a value 0 looks too impacting but 60s looks acceptable default value.
+1
The risk of the -1 default is that "restart the server" becomes a "solution" when that's not really what we want - we need a balance between self-healing and resource management.
I think that given LDAP is "eventually consistent" having a delay window before the group updates is completely reasonable - given these are (hopefully) infrequently changing groups, we could even extend to 120s or 300s by default to avoid too much load. It comes down to "what would an admin reasonably expect".
I would support any value of say ... 15s or higher for this change, and think that "correct by default" is what we should aim for.
Metadata Update from @spichugi: - Assignee reset
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/3173
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 - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.