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
84dba17..cd90857 master
Metadata Update from @tbordaz: - Issue set to the milestone: 1.3.8 (was: 0.0 NEEDS_TRIAGE)
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
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.
ImportTask
ExportTask
ttl
Metadata Update from @vashirov: - Issue status updated to: Open (was: Closed)
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)
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.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix
Login to comment on this ticket.