[Pulp-list] Importer/Distributor API Change

[Nick Coghlan]

On 03/12/2012 10:08 PM, Jay Dobies wrote:
>> - I want to be able to set summary & details even for a *failed* sync
>> job. Currently, marking a job as failed requires throwing an exception,
>> which means summary and details don't get set in the JSON reply. This
>> doesn't work well for PulpDist, since it means I need to have two
>> completely different ways of extracting information in the client
>> (depending on whether the job was marked as a "success" or a "failure"
>> at the Pulp level). Or, I do as I do now, and even PulpDist failures are
>> marked as a "success" at the Pulp level :P
>
> This is a really good idea. If I remember correctly, that call already
> returns a report, so adding in a flag indicating overall result
> shouldn't be too hard. I'll add that soon under this sprint's bucket of
> sync enhancements.

Thanks, that should simplify some of my current code (which has to dig 
down into my job summary information to identify successful jobs).

>> - I need to provide users with access to the sync log while the job is
>> running (since that's the quickest and easiest way to figure out whether
>> an rsync job is genuinely stuck or is just taking a long time). There's
>> no native mechanism to support that, so I'm currently considering making
>> the sync log a content unit in its own right.
>
> That's the purpose of the set_progress call in the sync conduit.
> Unfortunately, it still doesn't actually do anything. There was a recent
> change to that API to have it simply accept a dict as the status; we
> were finding cases where a "Step X out of Y" scenario just didn't make
> sense. It follows the normal paradigm of including what makes sense for
> your importer implementation and it's the client's task of interpretting
> the data.

Yep, that should work. Last time I looked at that API it was still set 
up just for "step X of Y", where I really just want to provide an 
updated version of the raw sync log for the current set of PulpDist 
importers.

I may still have to do some kind of workaround near-term, but I'll be 
looking to switch over to the set_progress() API once it is implemented.

>> - It would be handy to have an easy way for the client to request just
>> the "latest successful sync history entry" and the "latest sync history
>> entry". The general query API may already support that (as I said, I'm
>> still working without the capabilities of the older API).
>
> This exists at /v2/repositories/<repo_id>/history/sync/. It's a GET call
> that currently supports a "limit" query parameter. They should be
> ordered with the most recent first, so "limit=1" should answer your
> second question.

Excellent, I've added an item to the PulpDist BZ to use that option when 
appropriate.

> From there it should be a pretty trivial enhancement
> for us to add in a query parameter to filter out based on result as well

That will work, especially once the sync result reporting is updated to 
let me control the success flag directly.

Regards,
Nick.

-- 
Nick Coghlan
Red Hat Engineering Operations, Brisbane