Update using ip instead of fqdn

Are those new listers landed yet?

Cookers migrated:

│ cookers [2022-09-26 14:48:17,948: INFO/MainProcess] Task swh.vault.cooking_tasks.SWHCookingTask[722de41d-0f88-45f7-ad06-3fb65f3978e1] received                                                                                              │
│ cookers [2022-09-26 14:48:54,924: INFO/ForkPoolWorker-1] Task swh.vault.cooking_tasks.SWHCookingTask[722de41d-0f88-45f7-ad06-3fb65f3978e1] succeeded in 36.83566682902165s: None

Rebase

I also don't understand why worker04 doesn't have any issue with rancher as it uses
the default 127.0.0.1 configuration

Add node worker04 to the mix

Remains a bunch of services not existing yet in the elastic stack (vault cooker, deposit checkers and indexer journal clients).
So the plan would be to integrate those in the elastic stack.

• nixguix: Keep only one url as origin and other urls as fallback ones

Align file tarball listing on what we do for tarballs.

Hum, for the 7 false, I have to check. For the 88 packages with no-origin, it is more
annoying. Well, some are metapackages as gcc-toolchain, so they can be skipped. Is it
ok for you to let this 'no-origin' type? For some others, I have to check if they are
covered elsewhere.

For ^, something like this would do [1]

• nixguix: Keep only one tarball origin sending along fallback urls

Thanks for all that ^! And great pointers!

I've moved around the parent task as the lister should be able to do something about this.

This perimeter enters the scope of T3781.

I either remembered an old stateless implementation or i remember another
implementation altogether.

In T4478#91695, @ardumont wrote:

But on my side, the "stateless" lister starts from the problematic page (17), and then
plainly stops... [2].

Note that there is a misbehavior in terms here for that "stateless" typed lister. If it
is indeed a stateless lister, it should start from scratch each time it runs. If it has
an incremental behavior (it seems so from that described behavior) then it should be
probably typed differently.

Bingo, it is a stateful lister... so nevermind my remark ^

I either remembered an old stateless implementation or i remember another implementation

altogether.

I'll unstuck the situation by resetting that state.

@KShivendu, you may want to deal with that edgecase though (please, create another
task/diff if you want to address it). If the first page of the saved state is not
working, next time it triggers, the current lister implementation won't list anything
¯\_(ツ)_/¯.

[1]

10:41:16 swh-scheduler@db1:5432=> select * from listers where name='gogs';
+--------------------------------------+------+---------------+-------------------------------+-------------------------------------------------------------------------------------------------------+-------------------------------+
|                  id                  | name | instance_name |            created            |                                             current_state                                             |            updated            |
+--------------------------------------+------+---------------+-------------------------------+-------------------------------------------------------------------------------------------------------+-------------------------------+
| ec6c8408-42f9-47b8-b045-5a812d4a0eff | gogs | try.gogs.io   | 2022-09-13 09:13:00.647726+00 | {"last_seen_repo_id": 7591, "last_seen_next_link": "https://try.gogs.io/api/v1/repos/search?page=17"} | 2022-09-20 09:08:40.081281+00 |
+--------------------------------------+------+---------------+-------------------------------+-------------------------------------------------------------------------------------------------------+-------------------------------+
(1 row)

Time: 5.468 ms

But on my side, the "stateless" lister starts from the problematic page (17), and then
plainly stops... [2].

Note that there is a misbehavior in terms here for that "stateless" typed lister. If it
is indeed a stateless lister, it should start from scratch each time it runs. If it has
an incremental behavior (it seems so from that described behavior) then it should be
probably typed differently.

ah i think i got it...

As a shot in the dark, i've changed the list task arguments [1] but i'd be surprised if that'd change anything...

I noticed this but that's not what's happening in staging for some unknown reason [1]