Story #3041
closedAs a user viewing a consumer's history, I get a reference to the associated task
0%
Description
Let's say I install the pulp consumer on a host, bind it to an RPM repository, and schedule the installation of a package. If I start GETting /pulp/api/v2/consumers/<consumer_id>/history/?event_type=content_unit_installed
, I'll initially get responses like this:
[]
Eventually, a new event will be listed:
[{'_id': {'$oid': '59ca98be14059a396d393282'},
'_ns': 'consumer_history',
'consumer_id': '41223be0-c0a8-4822-9a3d-0b6a81327c37',
'details': {'units': [{'type_id': 'rpm', 'unit_key': {'name': 'dog'}}]},
'id': '59ca98be14059a396d393282',
'originator': 'SYSTEM',
'timestamp': '2017-09-26T18:13:18Z',
'type': 'content_unit_installed'}]
The timestamp
in this task exactly matches the time for which this task was scheduled. In other words, this event indicates that a content unit installation has started, not that it has completed. So, what if I want to track the asynchronous task that's been fired off? How do I do that?
It can't be done. No task href is listed in this response. Furthermore, the id
listed in this response doesn't apper to correspond to the id
listed in any task at all, ever. On the test system on which this task was executed, journalctl | grep 59ca98be14059a396d393282
returned no text at all.
Furthremore, I think it is possible to track these content unit installation tasks. Here's a line from the system journal:
Sep 26 14:13:18 rhel-7-pulp-2-14 goferd[15597]: [INFO][worker-0] gofer.rmi.dispatcher:603 - call: Content.install() sn=606e2b7d-0178-48c2-afcd-2eedfc0399ad data={'task_id': 'c5740685-7da1-43cc-b0c7-4367133c12e3', 'consumer_id': '41 223be0-c0a8-4822-9a3d-0b6a81327c37'}
Task c5740685-7da1-43cc-b0c7-4367133c12e3 appears to track the installation of this schedule content unit installation.
This issue negatively affects QE's ability to test pulp-consumer in an automated manner. For an example of an affected issue, see Pulp Smash #611.
Updated by mhrivnak about 7 years ago
Did you try using the normal task API to look for that task?
Strange as it may sound, Pulp represents both "celery" tasks and "pulp-agent" tasks through that same data structure and endpoint, even though the tasks are fundamentally handled quite differently.
Updated by Ichimonji10 about 7 years ago
Did you try using the normal task API to look for that task?
Yes. Unfortunately, searching through the list of tasks after a scheduled task has been started causes an HTTP 5XX to be thrown. See: https://pulp.plan.io/issues/3042
Updated by ttereshc about 7 years ago
- Tracker changed from Issue to Story
- Subject changed from It's impossible to track the status of a scheduled task to As a user viewing a consumer's history, I get a reference to the associated task
- % Done set to 0
Updated by omaciel@redhat.com about 7 years ago
Here's what I expect from a Tasks API:
- POSTing to an API that creates a scheduled action should return a Task response
* This response should contain a unique task ID - GETting this task by its ID should return information about the scheduled task, including:
* State: pending, running, completed
* Status: completed, failed
For anyone who needs to programmatically create and track scheduled tasks, the actions above are crucial and this is what I expect from any REST API implementation dealing with scheduled tasks. Without it, there is not a lot of usefulness in the API... Can we please consider adding support for these suggestions to Pulp?
Updated by bmbouter over 5 years ago
- Status changed from NEW to CLOSED - WONTFIX