Bug 1100638
| Summary: | Mismatch between binding task search response and task obj initiation | ||
|---|---|---|---|
| Product: | [Retired] Pulp | Reporter: | dgao |
| Component: | API/integration | Assignee: | Barnaby Court <bcourt> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Preethi Thomas <pthomas> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 2.4.0 | CC: | bcourt, bmbouter, jmatthew, jsherril, mhrivnak, pthomas, rbarlow, skarmark |
| Target Milestone: | --- | Keywords: | Triaged |
| Target Release: | 2.4.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-08-09 06:55:01 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Make sure katello gets notified when this change is done, because it may require a minor change on their side. Michael, what type of change in the output from pulp will occur? The REST API seems to be returning the correct data structure, so I don't think there will be any change required for katello after all. This is probably just a parsing error in our python bindings. Michael, it looks to me that the REST API is in fact not returning the correct data structure:
u'spawned_tasks': [u'756345bd-ba30-4f33-b6fc-5da54cf44b0f']
According to our documentation[0], it should return the same structure as retrieving a single task, except wrapped in a list. It is wrapped in a list, but it should be a dictionary with a few attributes, not just a string of the task id.
Justin, I propose correcting the API for the task search to return what the documentation says instead. For example, the above would look more like this:
"spawned_tasks": [{"href": "/pulp/api/v2/tasks/756345bd-ba30-4f33-b6fc-5da54cf44b0f/",
"task_id": "756345bd-ba30-4f33-b6fc-5da54cf44b0f" }]
How does that sound?
[0] https://pulp-dev-guide.readthedocs.org/en/latest/integration/rest-api/dispatch/task.html#searching-for-tasks
Randy, yeah I'm okay with that change. Would each 'spawned' task include the full task details? (state, progress, etc..) or just those two attributes? Also, if you could get me a heads up of which pulp version this becomes a part of (when you figure it out of course). We'll need to coordinate the change downstream or else this will cause some major breakages :) Hi Justin, The spawned tasks would only include those two attributes, as per the documentation. All of our other task APIs also work this way, which is why we need to make this change. We'll let you know when we know which build this will be part of. Fix included in pulp-server-2.4.0-0.24.beta verified
[root@mgmt3 ~]# rpm -qa pulp-server
pulp-server-2.4.0-0.24.beta.el6.noarch
[root@mgmt3 ~]#
>>> pic.POST('/v2/tasks/search/',body={"criteria": {}})
Request Body
{
"criteria": {}
}
Response Body
[
{
"exception": null,
"task_type": "pulp.server.tasks.repository.sync_with_auto_publish",
"_href": "/pulp/api/v2/tasks/7cf423d2-5224-4967-8f4a-aad016694c07/",
"task_id": "7cf423d2-5224-4967-8f4a-aad016694c07",
"tags": [
"pulp:repository:supplementary",
"pulp:action:sync"
],
"finish_time": "2014-07-14T11:23:58Z",
"_ns": "task_status",
"start_time": "2014-07-14T11:23:57Z",
"traceback": null,
"spawned_tasks": [
{
"_href": "/pulp/api/v2/tasks/7209dd97-fd95-47bd-a153-cfa6c38ebf91/",
"task_id": "7209dd97-fd95-47bd-a153-cfa6c38ebf91"
}
],
This has been fixed in Pulp 2.4.0-1. |
There's an issue with task search using pulp bindings (pulp v2.4). Here's the response I'm getting back from the pulp server after the RestAPI call is made: {u'task_id': u'6c0edca1-b048-454a-a690-776f2f15d078', u'tags': [u'pulp:repository:rhs-2-for-rhui-server-source-x86_64', u'pulp:action:sync'], u'finish_time': 1400615714, u'_ns': u'task_status', u'start_time': 1400615700, u'spawned_tasks': [u'756345bd-ba30-4f33-b6fc-5da54cf44b0f'], u'progress_report': {u'yum_importer': {u'content': {u'size_total': 103251557, u'items_left': 0, u'items_total': 40, u'state': u'FINISHED', u'size_left': 0, u'details': {u'rpm_total': 40, u'rpm_done': 40, u'drpm_total': 0, u'drpm_done': 0}, u'error_details': []}, u'comps': {u'state': u'FINISHED'}, u'distribution': {u'items_total': 0, u'state': u'FINISHED', u'error_details': [], u'items_left': 0}, u'errata': {u'state': u'FINISHED'}, u'metadata': {u'state': u'FINISHED'}}}, u'queue': u'reserved_resource_worker-1.amazonaws.com', u'state': u'finished', u'result': {u'result': u'success', u'importer_id': u'yum_importer', u'exception': None, u'repo_id': u'rhs-2-for-rhui-server-sou! rce-x86_64', u'traceback': None, u'started': u'2014-05-20T19:55:00Z', u'_ns': u'repo_sync_results', u'completed': u'2014-05-20T19:55:13Z', u'importer_type_id': u'yum_importer', u'error_message': None, u'summary': {u'content': {u'state': u'FINISHED'}, u'comps': {u'state': u'FINISHED'}, u'distribution': {u'state': u'FINISHED'}, u'errata': {u'state': u'FINISHED'}, u'metadata': {u'state': u'FINISHED'}}, u'added_count': 0, u'removed_count': 0, u'updated_count': 40, u'id': u'537bb321edceaa54fce414d4', u'details': {u'content': {u'size_total': 103251557, u'items_left': 0, u'items_total': 40, u'state': u'FINISHED', u'size_left': 0, u'details': {u'rpm_total': 40, u'rpm_done': 40, u'drpm_total': 0, u'drpm_done': 0}, u'error_details': []}, u'comps': {u'state': u'FINISHED'}, u'distribution': {u'items_total': 0, u'state': u'FINISHED', u'error_details': [], u'items_left': 0}, u'errata': {u'state': u'FINISHED'}, u'metadata': {u'state': u'FINISHED'}}}, u'_id': {u'$oid': u'537bb314a9356d49c5! 57116f'}} The problematic piece is response_body['spawned_tasks']. After the response return, the binding code will try to wrap the response into a Task obj before returning. When it gets to https://github.com/pulp/pulp/blob/master/bindings/pulp/bindings/responses.py:112, it will try to instantiate another Task obj with the string obj. It seems like the client code is looking for a list of dictionaries inside response_body['spawned_tasks'], but instead only the task_id came back. This looks like a bug where the database object is being returned without being properly formatted.