After upgrading packages, and reboot.
This seems to have increased a bit its memory to something more sensible.
Let's see if the problem disappears altogether now.

but otherwise, lgtm ;)

one question inline.

or you could edit on the template directly? [1]

Adapt according to suggestion.

one comment inline

btw:

11:19 <+olasd> ardumont: we want the gateway services to run on the central Thanos host, don't we?
11:19 <+olasd> (to reduce the number of open ports and cross-tenant dependencies)
11:46 <+ardumont> Not sure we can? It wants access to the disk store? I'll double check
11:50 <+olasd> there's no disk store
11:50 <+olasd> only azure objstorage

Assuming the build it depends on is landed, tagged and released and this build goes green.

lgtm, one typo inline.

Use collected resources to generate the configuration file for thanos query service

wip: Rework logic to instantiate thanos query to lookup datastore (out of collected
resources and statically declared resources)

Address the simple part of the comments (had a bit of a fight with vagrant):

• sidecar: dedicate http and grpc port
• sidecar: expose only internal ip
• query: dedicate http and grpc port
• systemd service: use dynamic user
• stores list: use full $service:$port string

Revert wrong update

Update with the right diff id

Update

I've no idea if the cpu/memory/disk spec are large enough or not, I didn't find the info on the thanos documentation

Move that node to the admin vlan

Update reserved ip address

Its syntax is more convenient and it automatically deals with encoding. eg. wtpath = os.path.join(os.fsencode(self.tempdir_path), path) becomes wtpath = self.tempdir_path / path with pathlib

I see, maybe we could handle such change in another diff ? If I recall correctly, the subversion loader implementation could also be migrated to pathlib.

I just reused the current last migration run and added the swh-objstorage to the list of
repositories (not yet migrated). And the migration just broke on that repository.

You should be able to remove swh::deploy::worker::indexer_origin_intrinsic_metadata from swh-site/data/common/common.yaml, too

lgtm (i've triggered back the build)

one question on the last assertion test though.

Reopened as the need got clarified and the previous check used a repository which did not have any issues/merge-requests associated to it.
So let's check with a repo which does have those ^.

lgtm

ok, one question inline.

Workers which are running on buster [1] seems ok indeed so fine i guess.

lgtm but it's missing the test case around it. It should not be too hard to add a

scenario which lifts the flavor parameter, shouldn't it? possibly, but I had it tested
from swh-storage (D8067)

Heads up, current work to improve the jenkins tooling has been tested (docker-compose,
jenkins in docker, triggering pipeline with docker).

lgtm but it's missing the test case around it. It should not be too hard to add a scenario which lifts the flavor parameter, shouldn't it?