Bug 1008256

Summary: backend txn plugin fixup tasks should be done in a txn
Product: Red Hat Enterprise Linux 7 Reporter: Nathan Kinder <nkinder>
Component: 389-ds-baseAssignee: mreynolds
Status: CLOSED CURRENTRELEASE QA Contact: Sankar Ramalingam <sramling>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.0CC: mkubik, mreynolds, nsoman, rmeggins
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 389-ds-base-1.3.1.6-5.el7 Doc Type: Bug Fix
Doc Text:
Cause: Adding a task entry to the server, like the task created by running the fixup-memberof.pl script. Consequence: The task was not being done inside a transaction(if using backend transactions), and would not revert any updates if there was a failure. Fix: Perform the updates issued by the task inside a backend transaction. Result: The task operations perform as expected during success or failure.
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-06-13 10:59:32 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Nathan Kinder 2013-09-16 02:03:45 UTC
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/389/ticket/47512

automember fixup and linked attribute fixup tasks should be done in a transaction

Comment 1 Sankar Ramalingam 2013-09-16 16:12:36 UTC
Can this be verified on 389-ds-base environment? or only with IPA?

Comment 2 Rich Megginson 2013-09-25 19:01:08 UTC
Can this be verified on 389-ds-base environment? or only with IPA?

Comment 3 mreynolds 2013-09-25 19:19:29 UTC
This did not fix anything.  We just made sure all the plugin tasks are run inside a transaction.  It was originally hoped that this change would solve a deadlock issue with IPA/slapi-nis.  However, even with this change, that deadlock is still occurring.

Comment 5 Sankar Ramalingam 2014-02-04 06:53:11 UTC
(In reply to mreynolds from comment #3)
> This did not fix anything.  We just made sure all the plugin tasks are run
> inside a transaction.  It was originally hoped that this change would solve
> a deadlock issue with IPA/slapi-nis.  However, even with this change, that
> deadlock is still occurring.

Does it mean the bug is still not fixed or its a known issue?

Comment 6 mreynolds 2014-02-04 14:38:11 UTC
(In reply to Sankar Ramalingam from comment #5)
> (In reply to mreynolds from comment #3)
> > This did not fix anything.  We just made sure all the plugin tasks are run
> > inside a transaction.  It was originally hoped that this change would solve
> > a deadlock issue with IPA/slapi-nis.  However, even with this change, that
> > deadlock is still occurring.
> 
> Does it mean the bug is still not fixed or its a known issue?

No, it is fixed on DS, but we had hoped this DS fix would resolve an issue IPA was seeing(but it did not help IPA).

Comment 7 Namita Soman 2014-02-13 16:54:20 UTC
Please add steps to verify this in IPA

Comment 8 mreynolds 2014-02-13 18:47:34 UTC
(In reply to Namita Soman from comment #7)
> Please add steps to verify this in IPA

There are no steps to verify this.  It was a proactive change in the DS code.  It was added in hopes of fixing an issue with slapi-nis.  Even though it did not help with the slapi-nis issue, the code change was still appropriate to commit even though it didn't fix anything.

Comment 9 Nathan Kinder 2014-02-13 23:11:48 UTC
(In reply to mreynolds from comment #8)
> (In reply to Namita Soman from comment #7)
> > Please add steps to verify this in IPA
> 
> There are no steps to verify this.  It was a proactive change in the DS
> code.  It was added in hopes of fixing an issue with slapi-nis.  Even though
> it did not help with the slapi-nis issue, the code change was still
> appropriate to commit even though it didn't fix anything.

Correct.  This should be verified by sanity testing only.

Comment 10 Milan KubĂ­k 2014-02-17 12:43:35 UTC
Sanity test/acceptance run against 389-ds-base-1.3.1.6-18.el7 doesn't seem to indicate regressions.

Marking verified (sanity only) as per Sankar's instructions.

Comment 11 Ludek Smid 2014-06-13 10:59:32 UTC
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.