Bug 1409487

Summary:	New parameter nsds5ReplicaIgnoreMissingChange
Product:	Red Hat Directory Server	Reporter:	Marc Muehlfeld <mmuehlfe>
Component:	Doc-config-command-file-reference	Assignee:	Marc Muehlfeld <mmuehlfe>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Viktor Ashirov <vashirov>
Severity:	unspecified	Docs Contact:
Priority:	high
Version:	10.0	CC:	batkisso, gparente, lkrispen, msauton, nhosoi, rhel-docs
Target Milestone:	DS10.1
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-03-21 10:01:04 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Marc Muehlfeld 2017-01-02 08:43:02 UTC

A new configuration parameter nsds5ReplicaIgnoreMissingChange has been introduced to the replication agreement. The param takes either of the 3 values: never, once or always.

If the value is ...
- never | off: treat missing CSN as fatal
- once | on: ignore a missing CSN once; treat the second missing CSN as fatal
- always: ignore missing CSNs

The default value is 'never | off'.

Comment 3 Ludwig 2017-01-09 11:55:44 UTC

I haven't seen a reply to Noriko's suggestion of not documenting it in the general docs but only in the knowledge base.

But here is a a short description.  

In a replication session the supplier determines a csn to start sending updates to the consumer. If it cannot find this csn in its changelog, it cannot proceede and goes int backoff and will retry later. In a later session the consumer might have been updated by an other supplier and the start csn can be different.
But if the situation persists and replication does not continue the parameter nsds5ReplicaIgnoreMissingChange allows to use an alternative start csn which can be found. The default is not to use an alternative csn, to do a "kick start" of replication it can be set to "once" and it will use the alternative only once.
If an admin wants to keep replication always going, it can be set to "always", but this is not recommended

Comment 4 Marc Muehlfeld 2017-01-17 10:47:06 UTC

We documented this parameter in a KCS that is now available on the Customer Portal:
https://access.redhat.com/node/2853491/

Comment 7 Noriko Hosoi 2017-01-19 18:52:02 UTC

Thanks to Brian who found an issue in the KB doc.
https://access.redhat.com/node/2853491/

The entry to add the parameter nsds5ReplicaIgnoreMissingChange is not a replica entry, but an agreement underneath.

Current>
dn: cn=cn=replica,cn=*suffixDN*,cn=mapping tree,cn=config

Correct>
dn: cn=*agreement_name*,cn=replica,cn=*suffixDN*,cn=mapping tree,cn=config

Sorry, Marc.  I missed it in my review...

For more details, please take a look at the #c21 and #c22 in the original bug [1].

Also, as suggested by Brian, it'd be useful to add that modifying the parameter is dynamic (== no need to restart the server after adding it) and no need to run the replica initialization on the agreement, either.

Ludwig, please correct me if I'm wrong. ;)

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1391700

Comment 8 Marc Muehlfeld 2017-01-20 10:50:01 UTC

(In reply to Noriko Hosoi from comment #5)
> So, at the point, the environment will include RHDS 9.1 / RHEL 6.9.

I set a reminder and I will update the KCS article on 2017-03-21. 



(In reply to Noriko Hosoi from comment #7)

I updated the KCS article. It now includes the correct DN and the information that neither re-initializing the replication agreement nor restarting the server is required (Ludwig confirmed this).

Comment 9 Noriko Hosoi 2017-01-20 16:55:00 UTC

Thank you for updating the KCS, Marc!  Looks great.