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

Re: [Pulp-list] Importer/Distributor API Change



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


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