fixed with the workaround in D7972

Because it looks simpler and faster to have this workaround here.

is it not possible to use a sql script directly, in the idea of [1] ?
I suppose it will make the script simpler as the postgresql image logic will take care of running the script only during the database initialization.

This issue was a false lead, different snapshots are declared for the same origin letting me believe there were some duplicates.
I completely missed it and fall head first into the trap

only use the postgresql paramater to configure the max connection

update the parameter count limit according the new supported ones

I've also added the permissions to the user mirror-test-rw to create and destroy topics. So you should be able to manage the swh.test.objects[_privileged] topics lifecycle

btw the credentials are pushed in the credential store

heh, it misses the last part of the task (the commands to manage the topics)

Changing the status to resolved.
@douardda don't hesitate to reopen if it's not working as expected

Permission of users should be ok:

• mirror-test-rw

root@getty:~# diff -U3 /usr/local/sbin/create_kafka_users_rocquencourt_staging.sh create_kafka_test_users_rw_rocquencourt_staging.sh 
--- /usr/local/sbin/create_kafka_users_rocquencourt_staging.sh	2022-01-21 16:57:22.076322616 +0000
+++ create_kafka_test_users_rw_rocquencourt_staging.sh	2022-06-03 13:02:03.497371791 +0000
@@ -56,15 +72,15 @@
 	--entity-type users \
 	--entity-name $username

Topics created:

storage1 /opt/kafka/bin% TOPICS="content directory extid metadata_authority metadata_fetcher origin origin_visit origin_visit_status raw_extrinsic_metadata release revision skipped_content snapshot"

after some ingestion time, it seems the first analysis is wrong:

(provenance) provenance-client01:~$ sort ~/origin-client.log |grep Processing | uniq -c  | sort -n | tail -n 10
      6 INFO:swh.provenance.origin:Processing origin https://bitbucket.org/360factors/workflow-conditions.git
      6 INFO:swh.provenance.origin:Processing origin https://bitbucket.org/4s/cda-document-viewer.git
      6 INFO:swh.provenance.origin:Processing origin https://bitbucket.org/4tic/goc.git
      6 INFO:swh.provenance.origin:Processing origin https://bitbucket.org/ALEXks/sapfor_2017.git
      6 INFO:swh.provenance.origin:Processing origin https://bitbucket.org/ASIWeb/testcomplete.git
      7 INFO:swh.provenance.origin:Processing origin https://anonhg.netbsd.org/xsrc-draft/
      7 INFO:swh.provenance.origin:Processing origin https://anonhg.netbsd.org/xsrc-public/
      8 INFO:swh.provenance.origin:Processing origin https://anonhg.netbsd.org/xsrc/
     13 INFO:swh.provenance.origin:Processing origin https://bitbucket.org/9front/plan9front
     20 INFO:swh.provenance.origin:Processing origin https://anongit.kde.org/kdenlive.git

It's not as bad as expected, it seems only 2 clients are proceeding the same origin at the same time:

I'm not sure if the service should be stopped before being removed but otherwise it looks ok

fix typos according to the feedback

after rereading this together, it seems the worker activation is missing

• Is the scheduler section in 'swh::deploy::indexer_journal_client::config' still needed ?

update storage default url to match a local service deployed on the cluster

The target of this repository is staging / production or even test environments.

Remove testing values file

An interesting lead that could possibly explain what happened on the cluster : https://etcd.io/docs/v3.4/faq/#should-i-add-a-member-before-removing-an-unhealthy-member

FI: an odd number of nodes is recommended for an etcd cluster

The cluster is up and running.

Unfortunately, after several tries, we were unable to restart the cluster due to a problem with the etcd leader election / data on the nodes (probably wrong manipulation from us).
We finally destroyed the cluster (we had to follow [1] because the cluster was in an unstable state and rancher refused to remove it)

I tried to fix it too but without success, so I guess we can go with this diff until we find a better solution

• Following this page to cleanup all the current resources on rancher-node-intership[0-2]: https://rancher.com/docs/rancher/v2.5/en/cluster-admin/cleaning-cluster-nodes/
• restart the nodes
• Delete the deployment-intership cluster in rancher
• Add the desire kubernetes version in terraform
• Apply
• launch the docker command to register the nodes in each node

thanks, I forgot to mention that

The error when we try to declare a resource in 1.22:

rebase

rebase

edit commit message

The command name called by postfix[1] seems to not match the command name declared in the webapp[2]