[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[Pulp-list] status_path

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:

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)

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?

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]