Bug 1950385

Summary:	Freeipa nightly test failure: ipa_topo_util_cleanruv: failed to create cleanalltuv task
Product:	Red Hat Enterprise Linux 8	Reporter:	thierry bordaz <tbordaz>
Component:	ipa	Assignee:	Florence Blanc-Renaud <frenaud>
Status:	NEW ---	QA Contact:	ipa-qe
Severity:	high	Docs Contact:
Priority:	high
Version:	8.4	CC:	frenaud, idm-ds-dev-bugs, mreynolds, progier, rcritten, tscherf
Target Milestone:	beta	Keywords:	Reopened, Triaged
Target Release:	8.9
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	sync-to-jira
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-12-16 07:30:43 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 thierry bordaz 2021-04-16 13:49:59 UTC

Description of problem:
FreeIPA nightly tests frequently fail in the test test_integration/test_topology.py::TestCASpecificRUVs::test_replica_uninstall_deletes_ruvs. See for instance PR #533 in the test testing-fedora/test_topology_TestCASpecificRUVs.

Version-Release number of selected component (if applicable):
It popup in RHEL8 but it may also apply before


How reproducible:
It occurs not systematically on several ipa tests.
This bug is a mistery when looking at the task code but clearly it happens from time to time

Steps to Reproduce:
Not clearly identified

Actual results:
RUV task cleared too early

Expected results:
RUV task should stay longer (1day IIRC)

Comment 2 thierry bordaz 2021-10-06 15:15:10 UTC

Florence, do you know if this problem still occurs in your environment ?
Possibly already fix (monotonic time)

Comment 3 Florence Blanc-Renaud 2021-10-06 15:28:55 UTC

Thierry, we still see the issue in fedora (for instance with 389-ds-base-2.0.7-1.fc35.1.x86_64 389-ds-base-2.0.7-1.fc34.x86_64 or 389-ds-base-1.4.4.16-1.fc33.x86_64).

Comment 9 RHEL Program Management 2022-12-16 07:30:43 UTC

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.

Comment 10 Florence Blanc-Renaud 2022-12-16 07:45:42 UTC

Reopening as the issue is still happening.

Comment 13 Florence Blanc-Renaud 2023-05-17 09:10:59 UTC

The issue is still happening, see for instance this nightly run: http://freeipa-org-pr-ci.s3-website.eu-central-1.amazonaws.com/jobs/5cdc5c3c-f396-11ed-92d8-fa163ea04eff/report.html
Moving the stale date +6months to avoid auto-closure.

Comment 15 Pierre Rogier 2023-08-07 12:54:16 UTC

Moving back the bug to ipa component.

Last year, Mark's was right in assuming that the issue is not on 389ds side.
The latest report shows clearly that the problem is in freeipa code:

grep -Eni   "RUN \['ipa-replica-manage'|Background task created to clean replication data." report.html
shows that 'Background task created to clean replication data' is only printed twice: 
 while running 'ipa-replica-manage clean-ruv' (but not while running 'ipa-replica-manage del').

This means that cleanallruv function in ./freeipa/ipaserver/install/replication.py is not called while deleting a replica.
  (and a grep in freeipa code shows it is the only place that generate the ldap cleanallruv task) 
So RUV is not cleaned because nobody requested the ldap server to clean it.