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

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

5 years ago

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

5 years ago

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.

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

5 years ago

0036226..98bfccc 389-ds-base-1.4.0
c958047..50240de 389-ds-base-1.3.9
94e6f12..26517ea 389-ds-base-1.3.8

Metadata Update from @tbordaz:
- Issue assigned to tbordaz

5 years ago

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

5 years ago

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)

4 years ago

Commit 4677007 fixes this issue

Backported second fix...

e8f7c75..9ed2afa 389-ds-base-1.4.0 -> 389-ds-base-1.4.0

ed41355..ae4bfa8 389-ds-base-1.3.9 -> 389-ds-base-1.3.9

4e2ca67..03a4b3e 389-ds-base-1.3.8 -> 389-ds-base-1.3.8

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

4 years ago

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

3 years ago

Login to comment on this ticket.

Metadata
Related Pull Requests