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

[James Slagle]

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.

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

--
-- James Slagle
--