Story #1111: As an API user, I can purge completed task status records - Pulp

Actions

Send by e-mail Copy link

Story #1111

closed

As an API user, I can purge completed task status records

Added by mhrivnak over 9 years ago. Updated over 4 years ago.

Status:

CLOSED - CURRENTRELEASE

Priority:

Normal

Assignee:

sbhawsin

Category:

Sprint/Milestone:

Start date:

Due date:

% Done:

100%

Estimated time:

Platform Release:

2.8.0

Groomed:

Yes

Sprint Candidate:

Yes

Tags:

Pulp 2

Sprint:

Quarter:

Description

I suggest adding support for the DELETE method on this endpoint: https://pulp.readthedocs.org/en/latest/dev-guide/integration/rest-api/dispatch/task.html#listing-tasks

And require query args that limit it to final states. For example:

DELETE - https://mypulp/pulp/api/v2/tasks/?state=finished&state=error

If a request has no query args or specifies a non-final state, the response should be a 403.

Questions

Should this be done asynchronously? Mongo is probably real fast at dropping records, but is it fast enough? I'd start with doing it synchronously if we can't answer the questions quickly.
Can we safely delete tasks in the "cancelled" state? How can we know that the task isn't in the process of being cancelled? Maybe we can look at the "finish_time"?

Related issues

Actions

Copy link

Updated by mhrivnak over 9 years ago

Blocks Story #228: As a pulp-admin user, I can purge completed task records added

Actions

Copy link

Updated by bmbouter over 9 years ago

Actions

Copy link

Updated by bmbouter over 9 years ago

Actions

Copy link

Updated by mhrivnak over 9 years ago

Groomed changed from No to Yes

Actions

Copy link

Updated by sbhawsin over 9 years ago

Platform Release set to master

Actions

Copy link

Updated by mhrivnak over 9 years ago

Based on team discussion, let's start by doing this synchronously and see how it goes.

Cancellation does not appear to set a value for finish_time, so we can't use that to determine if it's safe to delete. We will need to look more closely at what the best thing is to do. If we delete one that's in the canceled state, it's possible that a worker process is still trying to write progress updates to the task. Maybe the best thing to do is ensure that wherever a task status is updated, it's ok if the object no longer exists and the update fails.

Actions

Copy link

Updated by rbarlow over 9 years ago

Blocked by Story #229: Add new task state: cancel_requested added

Actions

Copy link

Updated by rbarlow over 9 years ago

Blocked by deleted (Story #229: Add new task state: cancel_requested)

Actions

Copy link

Updated by rbarlow over 9 years ago

Related to Story #229: Add new task state: cancel_requested added

Actions

Copy link

#10

Updated by rbarlow over 9 years ago

We have a story about adding a new state called cancel_requested that will track the time between the cancellation request and the successful cancellation of the task. I went ahead and related that story to this story.

If we did #229 first, we'd be able to avoid this problem a little bit. It may still be possible for tasks to get stuck at cancel_requested if the message is missing from the broker somehow.

Actions

Copy link

#11