Bug 1044140

Summary:	Allow search to look up 'in memory RUV'
Product:	Red Hat Enterprise Linux 7	Reporter:	Nathan Kinder <nkinder>
Component:	389-ds-base	Assignee:	Rich Megginson <rmeggins>
Status:	CLOSED ERRATA	QA Contact:	Viktor Ashirov <vashirov>
Severity:	unspecified	Docs Contact:
Priority:	low
Version:	7.0	CC:	nhosoi, vashirov
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	389-ds-base-1.3.3.1-1.el7	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-03-05 09:29:59 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Nathan Kinder 2013-12-17 21:19:26 UTC

This bug is created as a clone of upstream ticket:
https://fedorahosted.org/389/ticket/47350

For a given replica, the ruv data structure is written back on a database entry with the DN "dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,<suffix>".

The database RUV is then look up by monitoring tools (like repl-monitor.pl or ldapsearch).
Since 1.2.8 (543633), see https://fedorahosted.org/389/ticket/564, in memory RUV is in sync with database RUV entry.

The fix for ticket 564, reintroduces a shift between in memory RUV/database RUV where in memory RUV reflects the exact state of the updates and database RUV is late ~30s.

This ticket is to create a new monitoring method to look up the in memory RUV.

We may use the replica_config_search (search on "cn=replica,cn="<suffix>",cn=mapping tree,cn=config") to handle that.

Comment 2 Viktor Ashirov 2015-01-19 03:57:25 UTC

$ rpm -qa | grep 389
389-ds-base-debuginfo-1.3.3.1-11.el7.x86_64
389-ds-base-libs-1.3.3.1-11.el7.x86_64
389-ds-base-1.3.3.1-11.el7.x86_64

I'm using script from the upstream ticket
$ ./test_ruv 

=============== Mon Jan 19 04:43:46 CET 2015 =====================

DB  RUV= bc7b4a0000007b0000
MEM RUV= bc7b4a0000007b0000
modifying entry "uid=usr0,ou=People,dc=example,dc=com"

DB  RUV= bc7d710000007b0000
MEM RUV= bc7d710000007b0000

=============== Mon Jan 19 04:43:56 CET 2015 =====================

DB  RUV= bc7d710000007b0000
MEM RUV= bc7d710000007b0000
modifying entry "uid=usr0,ou=People,dc=example,dc=com"

DB  RUV= bc7d7b0000007b0000
MEM RUV= bc7d7b0000007b0000

=============== Mon Jan 19 04:44:26 CET 2015 =====================

DB  RUV= bc7d7b0000007b0000
MEM RUV= bc7d7b0000007b0000
modifying entry "uid=usr0,ou=People,dc=example,dc=com"

DB  RUV= bc7d990000007b0000
MEM RUV= bc7d990000007b0000


In memory RUV from 'cn=replica,cn=\"<suffix\",cn=mapping tree,cn=config' and DB RUV from 'nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,<suffix>' return the same value. 

Marking as VERIFIED.

Comment 4 errata-xmlrpc 2015-03-05 09:29:59 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2015-0416.html