389-ds-base

#50177 import task should not be deleted too rapidely after import finishes to be able to query the status.
Closed: wontfix by vashirov. Opened by tbordaz.

Closed: wontfix
Reopen Issue

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 1663829

Description of problem:
when we do an on-line import, independently of the result of the task (failure
or success), the task should not be deleted as it's the case today but kept for
a while so as to be able to query the status.
Version-Release number of selected component (if applicable): latest rhel-7.6
version
How reproducible: always

Metadata Update from @tbordaz:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1663829

At task creation there is a possibility to tune the life time of the task (once completed). By default it is 2min and can be set to 1h.
An option would be to increase it up to 15min that looks acceptable.
In former script ldif2db.pl the change could be something like

195,196c195
< $ttl = "ttl: 900";
< $entry = "${dn}${misc}${cn}${nsinstance}${nsincluded}${nsexcluded}${nsldiffiles}${nsnoattrindexes}${nsimportencrypt}${nsmergechunksiz}${nsgenuniqid}${nsuniqidname}${ttl}";
---
> $entry = "${dn}${misc}${cn}${nsinstance}${nsincluded}${nsexcluded}${nsldiffiles}${nsnoattrindexes}${nsimportencrypt}${nsmergechunksiz}${nsgenuniqid}${nsuniqidname}";

Metadata Update from @tbordaz:
- Custom field origin adjusted to None
- Custom field reviewstatus adjusted to None

I think that 5-15min would be a really reasonable default for this, 2m may be too short. If something goes wrong you want a bit of time to look and go back to the results in these cases.

I'm leaning more towards an hour, or even 24 hours. For example, I'd love to know the status of previous automated tasks that might have run overnight, etc. Or you don't notice something went wrong until later in the day. It would be shame to lose this information especially since there is no harm in keeping these entries lying around for a while. Just my opinion :-)

I see no harm in longer like hour -> 24 hours.

PR https://pagure.io/389-ds-base/pull-request/50193

84dba1780..cd908573c master

Metadata Update from @tbordaz:
- Issue set to the milestone: 1.3.8 (was: 0.0 NEEDS_TRIAGE)

0036226b2..98bfccc81 389-ds-base-1.4.0
c9580477f..50240dea4 389-ds-base-1.3.9
94e6f128f..26517eadf 389-ds-base-1.3.8

Metadata Update from @tbordaz:
- Issue assigned to tbordaz

Metadata Update from @tbordaz:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

This should be also fixed in lib389. ImportTask and ExportTask classes do not create ttl attribute by default.

Metadata Update from @vashirov:
- Issue status updated to: Open (was: Closed)

Commit 4677007d fixes this issue

Commit 4677007 fixes this issue

Backported second fix...

e8f7c7551..9ed2afa58 389-ds-base-1.4.0 -> 389-ds-base-1.4.0

ed4135544..ae4bfa8a9 389-ds-base-1.3.9 -> 389-ds-base-1.3.9

4e2ca678f..03a4b3e0c 389-ds-base-1.3.8 -> 389-ds-base-1.3.8

Metadata Update from @mreynolds:
- Issue close_status updated to: None (was: Fixed)

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/3236

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix
Metadata
None
None
None
None
None
None
Related Pull Requests
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.