The configuration parsing/merging is currently done using swh.core.config and should be changed with T1410.

In a different test, I've seen the Too many request error, but only after Ctrl-C, with an asyncio issue:

ERROR:root:Unknown name during lookup: 'HEAD'
   unique: 1866, error: -2 (No such file or directory), outsize: 16
^CERROR:asyncio:Task exception was never retrieved
future: <Task finished name='Task-45' coro=<_session_loop() done, defined at /home/zack/.virtualenvs/swh/lib/python3.8/site-packages/_pyfuse3.py:28> exception=HTTPError('429 Client Error: Too Many Requests for url: https://archive.softwareheritage.org/api/1/content/sha1_git:642be81e2679d4524e736bafe6c4576360a9fd5c/raw/')>

This might be the key issue here, a missing (async) exception handler somewhere.

Looks like a lot of unrelated error are hidden behind "unknown SWHID". For instance, using the Web API via the VPN with the VPN down, results in that error too, with the syscall hanging.
There seems to be two things to fix about this:

• more appropriate error reporting (rate limit exceeded, can't connect to API server, etc.)
• the syscall should not hang, but rather return the user space an appropriate failure (note indeed that these hangs are bad, of the kind you can't Ctrl-C out of)

Fixed in 259757e6fc0a.

Also: what are the cons of adding a umount command with just wraps fusermount -u?

We can't expect all users to read the tutorial, that just doesn't happen in the real world :-)
If we don't add an explicit umount command, we should at least document how to unmount also in the doc of the mount command

I think we should add a full example of using (+ unmounting) the FUSE VFS in the tutorial doc (T2676), and not an extra umount command.

In T2702#50857, @haltode wrote:

To unmount you can use fusermount -u /mntdir

as @haltode suggests, that's how i unmount my sshfs mount point for example.

To unmount you can use fusermount -u /mntdir

From the design doc:

lookup() should ideally be O(1).

Job 188 indeed failed. Let's see if 189 is the right one!

FWIW, this is a bit trickier than the resolution for T2654 as this job uses docker via the plain "jenkins clouds" integration.

While we wait for a proper solution, I think there is nothing stopping swh fuse from loading a configuration file by default if it exists and -C is not passed on the CLI.
We should just move -C up one level (from swh fuse mount to swh fuse) and do something similar to what swh-scanner does.
The location of the file might change in the future as a consequence of T1410, but meh, it's not a big deal.
We can stay on the safe side for now and only support ~/.config/swh/fuse/fuse.yml. And we will worry about merging with a global config file later.

Closed by @vsellier with rCJSWH5ade7a89a66b0ac6f12c00601f7e996f49e703e3

I failed to successfully execute mount on the container without the privileged option so I finally configured the swh-fuse job with this option.