[Pulp-list] Importer/Distributor API Change

[Jay Dobies]

> Thanks!
>
> I've been meaning to get you some feedback on the sync result reporting
> API, but haven't found the time to make it vaguely coherent and work out
> what I should be dealing with at the plugin level and where it would be
> good if the Pulp API could help out.
>
> I'm also still writing to the v2 API as it existed around 0.254 or so,
> so it's also possible there are some new features I'm not using yet.
>
> However, I figure even my half-formed feedback should be somewhat
> useful, so here's a rough version:
>
> - 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.

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

> - 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. 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 
(ideally, we'll find time to add "skip" as well to support pagination on 
results).

> Regards,
> Nick.

Thanks for the feedback :)



-- 
Jay Dobies
Freenode: jdob @ #pulp
http://pulpproject.org | http://blog.pulpproject.org