we now have this space available:

the {exception:.../args:....} proposal + re-raising in the client looks good to me

We should standardize on :

• an HTTP error code (400 / Bad Request ?)
• a serialization format for the answer (JSON, probably serializing the error type and error args), e.g.

{
    'exception': e.__class__.__name__,
    'args': e.args,
}

and then deserialize that and raise in the client.

• code updated and deployed on worker0*
• all swh workers are currently running http://moma.internal.softwareheritage.org:5555/workers

As a first step to address this, in rDSTOTb841c72f6a240eac8131e40614c9ce20d75b1c96 I've checked into swh-storage-testdata several sample repositories, both as submodules and fast-export dumps.
Starting from those, we now need a Makefile target that batch import them into the SWH DB, and recreate the test database dumps.

now blocked due to the issues on sesi-pv-lc2 after the reboot :-/

just pinged Laurent, Cc:-ing swh-devel

The repository is now setup on pergamon:/srv/softwareheritage/repository

All the methods for git loading are written as of rDSTO2ccb3a502449

Done in rDSTOaf41d2084f46

done in rDSTOcc82413b4ee0

gzip (+ checksum verification) started on sesi-pv-lc2, using code in P8.
17 jobs being run in parallel, one for each store under /antelink/

https://intranet.softwareheritage.org/index.php/Swh_git_loader_stats_round_1