jortel at redhat.com
Mon Aug 15 20:22:27 UTC 2011
On 08/15/2011 03:20 PM, Jason L Connor wrote:
> On Mon, 2011-08-15 at 10:27 -0500, 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:
>> 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?
>> Pulp-list mailing list
>> Pulp-list at redhat.com
> This actually seems like a perfectly reasonable approach to me that will
> not only cleanup our code base, but also take advantage of the new task
> query api for something more than just debugging.
> The original 'status_path' was implemented for the 1-off async call of
> repo sync, and then duplicated as we added more async calls. It makes
> much more sense to keep only 1 call in the api to check the status of
> these tasks instead of 4.
> Changing the permissions is also a non-issue as they only reflected the
> original debugging motivation behind implementing the task api in the
> first place.
> In fact, I'd take the proposal a step further and suggest that we use
> the task api to cancel async tasks as well instead of individually
> implemented one-offs in the apis like we currently have.
> Nice proposal Jeff. :)
> Pulp-list mailing list
> Pulp-list at redhat.com
More information about the Pulp-list