Review tracking in T937

Done in rDVAUe8419e9b9f16 (at least the "just in time" version, the other is more a research project than a release blocker...)

For now we allow to retry as soon as the bundle status is set as "failed". rDVAU3a3c337107e6 implements the failure state.

New URL scheme was done in rDWAPPS195058a21902, dispatch between GET and POST in rDWAPPS03406f1d07af , and I made some changes in the Vault to behave nicely with the RPC and the documented exceptions in rDVAUd95bf6d37bec .

In T743#16529, @seirl wrote:

• shouldn't the format be a parameter instead of a part of the URL? i.e., ?format=foo instead of /foo at the end?

I see some reasons why not:

• shouldn't the format be a parameter instead of a part of the URL? i.e., ?format=foo instead of /foo at the end?

First of all thanks for this useful summary @seirl !

My current idea for the user-facing api is below. I have highlighted in bold the
things that require decisions or comments.

You can add swh.indexer.storage.db.Db to your list.

The current install works but is very clunky, mostly because we're not using swh.scheduler oneshot tasks. I'm adding that as a dependency.

The internal API has been done and in use for a while, so I'm closing this task.

I'm closing this and adding a new snapshot specific task.

The Vault prototype is "done", now the other remaining tasks should be task roots with the Vault project tag. I'm closing this meta-task.

This is already well beyond a prototype, so I'm closing this task.

As the "prototype" part of the vault is definitely over, I'm closing this task.

It works perfectly, thank you!

we had to change a setting on the storage device, it should now work as expected.

I have a problem with the NFS mountpoint: I'm using a non-root user for the service that reads and write on the vault, but I can't write on the NFS mountpoint. When I create a directory with the root user on the mountpoint, it gets created with uid/gid = 4294967294 (2^32-2), and I can't chown them to an uid/gid that my user would be able to write to:

That was the plan, yes.

And what would be the actual on-the-wire serialization format used to send the bare repo to users? Some sort of archive of the .git dir or what?

What is needed now is mainly to change the way formats are given in parameter (revision_gitfast/<hash> -> revision/<hash>/gitfast maybe?)