[Pulp-list] status_path

[Jeff Ortel]

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:
>>
>> <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
>
> 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.

Good idea.

>
> Nice proposal Jeff. :)

Thanks.
>
>
>
>
> _______________________________________________
> Pulp-list mailing list
> Pulp-list at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-list