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

Re: [Pulp-list] Agent: Package.install() API

On 11/10/2011 08:58 AM, James Slagle wrote:
On Thu, Nov 10, 2011 at 09:43:17AM -0500, Jay Dobies wrote:
Currently, we just grab it out of the task 'result' which has concerned
me lately. The more I work with katello and other external (non pulp
CLI) users of our REST API, the more I notice these kinds of things. For
the package (and package group) install flows which include errata, we
pass data back to the REST API call through the task which exposes our
internal tasking and manager layer to the REST caller. This has
concerned me for the past few days. I'm in the process of raising this
for discussion separately.

The reason I ask is because next week I was planning on putting
together ideas for v2 repo history that will store much more
reportable data on syncs, publishes, etc. I'm with you; I think we
need to move more into that direction than using something as low
level as tasking.

I know I'm coming on a bit late to the discussion, but this seems relevant to
what I'm currently working on.

I also think we could do a better job of cleaning some of these API's up to
not be so tasking dependent.  For instance, in order for any client (our CLI
or otherwise) to get the next sync time for a repo, it gets all tasks for the
repo, sorts them, looks for a running one, then tries to deduce the the next
sync time based on the logic of if a current sync is running and the next sync
time is in the past or future, etc.  This requires clients to have detailed
knowledge of how our tasking system works, such as what does it mean for a
recurring scheduling task that has a next sync time in the past?

It should be one simple call from the client perspective, "give me the next
sync time for this repository".  I'm actively working on moving logic like
this server side, so it is a simple call, b/c I see that as a prerequisite
before I can then make the call batch oriented..."give me the next sync time
for these 100 repos".  The same idea applies to current sync status as next
sync time, etc.

I agree.  Returning a list of tasks here instead of the answer can be improved.

I dont think there is overlap. I'm focusing on APIs that legitimately return task objects and/or flows that require task/job status queries. My concern with this is that we return the raw task/job object (actually a dict representation created with a task_dict(), function IIRC) instead of a 'task' REST resource that is independent of the underlying tasking subsystem and manager layer.

More on this in a separate thread.

Anyway, thought I'd bring it up, since I'm not sure how what you're doing
might overlap with this effort.

-- James Slagle

Pulp-list mailing list
Pulp-list redhat com

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