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.

In T3032#58243, @anlambert wrote:

Two possible solutions here:

• use stretch/updates, buster/updates, ... as suite names
• add specific URL template processing in debian lister implementation

I would go for the second one.

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

1. kibana0
2. The server was updated using the same procedure used for logstash0
3. there is no error detected when puppet is running
4. all the services are correctly started

1. logstash0 upgrade

production nodes are upgraded :
For each node :

• disable shard allocation:

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

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

We haven't had the capacity of making the azure infrastructure perform as well as the in-house one, to the point where the web frontend wasn't really useable.

There is no azure kafka cluster anymore...