There is no DELETE implemented for the URI v2/tasks/{task_id}. Instead, when a task reaches a terminal status, it gets an 'expires_at' datestamp. (The task time-to-live is a config option, default is 48 hours.) Tasks are soft deleted opportunistically as part of the task-list call [0]; however, there is a check in the code that only (soft) deletes the tasks that are owned by the user making the task-list call. The problem is that in the interoperable image import workflow, the user who makes the import call owns the task, but by default, this user does not have access to the Tasks API calls, which are governed by the "tasks_api_access" policy. What will happen is that when an admin does the task-list call, all tasks will be displayed, and the expired ones will *not* be soft deleted because the admin does not own them.
The fix is probably simply to remove the ownership check in the _task_soft_delete function. This will be fine even for installations that decide to allow all users access to the Tasks API. After all, when user A's tasks have expired, the next time user A makes a task-list call, those tasks won't be seen. So who cares if those expired tasks are removed when user B makes a task-list call before user A does? (User B isn't going to see them, they will just be soft deleted.) The key thing is that expired tasks will disappear sometime after they expire but before user A receives a task-list response, just as they are now.
The point of the "opportunistic" deletion strategy was so that there wouldn't be a need to have some daemon continually polling the database to soft delete expired tasks. So I don't think there is a need to check task ownership.
[0] https://github.com/openstack/glance/blob/418488ff2d40b60ad44484e9f1a0660cdbb17331/glance/db/sqlalchemy/api.py#L1503
Fix proposed to master: https:/