Default value of nsDS5ReplicaBindDNGroupCheckInterval should be changed

[389-ds-bot]

Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/50114

• Created at 2019-01-03 10:22:47 by tbordaz (@tbordaz)
• Assigned to nobody

---

Issue Description

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.

Package Version and Platform

Since 1.3.5

Steps to reproduce

1. Create a replica with nsDS5ReplicaBindDnGroup and check nsDS5ReplicaBindDNGroupCheckInterval value

Actual results

nsDS5ReplicaBindDNGroupCheckInterval=-1

Expected results

nsDS5ReplicaBindDNGroupCheckInterval=3 fetch at next bind 3s later. nsDS5ReplicaBindDNGroupCheckInterval=0 fetch at each bind

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2019-01-03 17:47:44

Metadata Update from @mreynolds389:

• 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

[389-ds-bot]

Comment from lkrispen (@elkris) at 2019-01-29 14:23:26

Simon will start with this

[389-ds-bot]

Comment from spichugi (@droideck) at 2019-01-29 15:28:55

Metadata Update from @droideck:

• Issue assigned to droideck

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2019-08-23 22:28:15

Is this still an issue?

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2019-08-23 22:28:15

Metadata Update from @mreynolds389:

• Issue set to the milestone: 1.4 backlog (was: 1.3.8)

[389-ds-bot]

Comment from lkrispen (@elkris) at 2019-08-27 10:53:35

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

[389-ds-bot]

Comment from tbordaz (@tbordaz) at 2019-08-27 15:24:54

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.

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2019-08-27 15:35:17

I agree that a value 0 looks too impacting but 60s looks acceptable default value.

+1

[389-ds-bot]

Comment from firstyear (@Firstyear) at 2019-08-29 02:04:21

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.

[389-ds-bot]

Comment from spichugi (@droideck) at 2020-06-24 16:24:54

Metadata Update from @droideck:

• Assignee reset