Bug 1950385 - Freeipa nightly test failure: ipa_topo_util_cleanruv: failed to create cleanalltuv task
Summary: Freeipa nightly test failure: ipa_topo_util_cleanruv: failed to create cleana...
Keywords:
Status: NEW
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: ipa
Version: 8.4
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: beta
: 8.9
Assignee: Florence Blanc-Renaud
QA Contact: ipa-qe
URL:
Whiteboard: sync-to-jira
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-04-16 13:49 UTC by thierry bordaz
Modified: 2023-08-14 14:12 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-12-16 07:30:43 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 4442 0 None open Freeipa nightly test failure: ipa_topo_util_cleanruv: failed to create cleanalltuv task 2021-04-16 13:51:34 UTC
Red Hat Issue Tracker FREEIPA-10229 0 None None None 2023-08-07 12:57:08 UTC

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.


Note You need to log in before you can comment on or make changes to this bug.