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

Re: [Pulp-list] status_path



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

Nice proposal Jeff. :)

-- 
Jason L Connor
linear on freenode #pulp
http://pulpproject.org/
RHCE: 805010912355231
GPG Fingerprint: 2048R/CC4ED7C1

Attachment: signature.asc
Description: This is a digitally signed message part


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