I am aware that we'd need to coordinate this change with katello.
On 08/15/2011 10:27 AM, Jeff Ortel wrote:
Last sprint, I reviewed both consumer and consumer group flows as related to
package &
package group install. This includes packages installed as part of errata
installs as
well. In each of these flows, the consumers, consumergroups and repositories
controllers
instrument the returned task dict with a "status_path". The path is call back
into the
controller with the task ID. Each of these (3) controllers have duplicate
implementations
as follows:
<snip>
task_info = self.task_status(action_id)
if task_info is None:
return self.not_found('No %s with id %s found' % (action_name, action_id))
return self.ok(task_info)
</snip>
We also have a Task WS controller added primarily for debugging which can also
be query a
task by ID which returns a summary of the task including its status. Last
sprint I added
the "job" stuff and chose not to follow this pattern as it seemed to add
complexity and no
value (unless I missed something).
Since we now have a REST api to query for both job and task summary
information, I'd like
discontinue the use of task['status_path'] and simply have the CLI (and misc
clients) use
the JobAPI.info() and TaskAPI.info() when polling for job/task status. To do
this, I would
need to change perms on controllers/Task.GET() from super_user_only=True to:
READ.
Any Objections?
Is there value in the current approach that I'm missing?
_______________________________________________
Pulp-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/pulp-list
_______________________________________________
Pulp-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/pulp-list
