The slide of the restrospective of the experiment are available at : https://hedgedoc.softwareheritage.org/VOP9qh1MTqm4DjPQfFgNbQ

It was not easy to know if it's a lot of call or long running calls because it's regular sample and we don't have this granularity.

LGTM

All the production nodes (`search-esnode[4-6]') are upgraded to bullseye

All the nodes are updated

• search-esnode0 updated without errors

The upgrade by itself was made with the same command as explained previously.
The shard allocation was disabled during the process to avoid unnecessary movements of shard in the cluster

• The server was updated using the same procedure used for logstash0
• there is no error detected when puppet is running
• all the services are correctly started

1. logstash0 upgrade

production nodes are upgraded :

• stop the journal clients:

root@search1:~# systemctl stop swh-search-journal-client@indexed
root@search1:~# systemctl stop swh-search-journal-client@objects

• flush the index to speedup the recovery

curl -XPOST http://search-esnode4:9200/_flush

For each node :

• disable shard allocation:

cat > /tmp/shard_allocation.json <<EOF
{
  "persistent": {
    "cluster.routing.allocation.enable": "primaries"
  }
}
EOF

rebase

fix a typo in the commit message

https://github.com/mvo5/unattended-upgrades/blob/5d05cd182325bad80558df53968a06c119f60746/data/50unattended-upgrades.Debian#L13
'n' is an alias for 'codename' so everything should be ok

The staging elasticsearch is migrated to 7.15.2, everything looks good.

Disable the new embedded geoip database
It creates and regularly update a .geoip_database index
not used by swh_search, so removing it

thanks for having fixed this

remove useless response code update

• journalbeat and filebeat are migrated on all the nodes
• after the lag recovery and the fix of the closed indexes script, everything looks good