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

Thu Nov 10 16:02:11 UTC 2011

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.