[Pulp-list] status_path

[Jeff Ortel]

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
> Pulp-list at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-list