Release 2506 distribution

[jpraynaud]

Why

In order to deploy new features, improvements and bug fixes, we need to release a new distribution.

What

Create and release a new distribution 2506

Important

• Bump minor versions:
  • client
  • signer
  • aggregator
• 🔥 Blocked by Missing debug and info logs in Mithril nodes #2227
• 🔥 Blocked by Signer does not handle properly signature signed entity timeout #2229
• 🔥 Blocked by Grafana aggregator dashboard is not working on release networks #2230
• Announce Upgrade the deprecated ubuntu-20 builders in CI #2216
• Upgrade release-preprod VM from e2-highmem-2 to e2-highmem-4
• Upgrade to Cardano node 10.1.4
  • in pre-release-preview
  • in release-preprod
  • in release-mainnet
• Activate the HTTP traffic compression in:
  • in pre-release-preview
  • in release-preprod
  • in release-mainnet
• Import the immutable file digests in the aggregator database
  • in pre-release-preview
  • in release-preprod
  • in release-mainnet

Distribution +1:

Note

• TBD

How

Phase 1: Prepare distribution

• Run a backward compatibility test in the CI on the unstable distribution
• Upgrade repository dependencies (with runbook)
• Check that all minor versions of all crates have been bumped for breaking change (if needed)
• Check if versions of repository linked crates are correct for publication to crates.io(mithril-common, mithril-client)
• Check if Cardano minimum supported versions in networks.json must be updated following the runbook
• Merge a PR for rotating the CHANGELOG.md (set the distribution version)
• Create a draft PR for rotating the documentation

Phase 2: Rollout pre-release distribution

• Tag and deploy a 2506.0-pre pre-release distribution on the pre-release-preview network
• Fill highlights, distributions compatibility and release notes sections in the pre-release page on GitHub
• Import the immutable file digests in the aggregator database in pre-release-preview with process
• Make sure pre-release-preview is working as expected
• Make sure Grafana dashboards are fetching data for pre-release-preview
• Make sure libraries version next have been published on npm registry
• Run an all green client multi-platform test in the CI
• Run an all green aggregator stress test in the CI
• Run a Cardano transaction prover benchmark:
  • Store results in the issue
  • Make sure that there is no performance drop since last release
• Announce the pre-release on discord channel
• Announce any breaking change in:
  • #cardano-scaling slack channel for pre-release
  • #mithril-lace slack channel for pre-release
  • #blockfrost-scaling slack channel for pre-release
  • Cardano Foundation IBC bridge team
• Wait for at least 3 signers running the new version (could be more if era change is tested) over at least 2 epochs

Phase 3: Rollout release distribution

• Tag and deploy a 2506.0 release distribution on the pre-release-preview network
• Fill highlights, distributions compatibility and release notes sections in the release page on GitHub
• Make sure pre-release-preview is working as expected
• Update networks compatibility table in release notes
• Stop all the cardano nodes of release-preprod as the VM will be updated with process
• Release the 2506.0
• Import the immutable file digests in the aggregator database in release-mainnet with process
• Make sure release-mainnet is working as expected
• Make sure that the VM of release-preprod has been updated properly with process
• Import the immutable file digests in the aggregator database in release-preprod with process
• Make sure release-preprod is working as expected
• Rotate the KES keys of the SPOs on release-preprod if needed
• Make sure libraries have been published on crates.io
• Make sure libraries version latest have been published on npm registry
• Make sure Grafana dashboards are fetching data for release-mainnet
• Make sure Grafana dashboards are fetching data for release-preprod
• Merge the PR for rotating the documentation
• Merge a PR for rotating the CHANGELOG.md (updating the release date of the distribution)
• Announce the release on discord channel (with breaking-change, upcoming features activation, ...)
• Announce any breaking/new feature change in:
  • #cardano-scaling slack channel for release
  • #mithril-lace slack channel for release
  • #blockfrost-scaling slack channel for release
  • Cardano Foundation IBC bridge team
• Update Hydra tutorial if client breaking change for database restoration
• Restore crates publish steps for mithril-client in CI and Pre-release workflows
• Dev blog post:
  • Distribution 2506
• Fix SSH keys
  • pre-release-preview
  • release-preprod

[jpraynaud]

Upgrade VM in place process

Prepare the upgrade

Connect to the VM:

export VM=aggregator.release-preprod.api.mithril.network
ssh curry@$VM

Once connected, create a temp directory:

export TMP_DIR=/home/curry/tmp
mkdir -p $TMP_DIR

Make a clean stop of the Cardano nodes:

docker ps --format '{{.Names}}' | grep cardano > $TMP_DIR/docker-ps-cardano.txt
cat $TMP_DIR/docker-ps-cardano.txt | xargs -I '{}' docker stop '{}'

Disocnnect from the VM:

exit

Make a manual snapshot of the data disk in GCP:

export SNAPSHOT_ID=mithril-release-preprod-...
export SOURCE_DISK=mithril-release-preprod-data
gcloud compute snapshots create $SNAPSHOT_ID --source-disk $SOURCE_DISK --snapshot-type STANDARD --source-disk-zone europe-west1-b

Run the terraform deployment to upgrade the VM

Run the deployment with the correct GitHub actions workflow that will upgrade the VM in place.

Check that the data disk is properly mounted

Once the VM has been modified in place, check that all the data disk is properly mounted:

lsblk | grep sdb | grep "/home/curry/data"

Case 1: the disk is properly mounted

If the previous command returns an entry, the data disk is mounted to the data folder and there is nothing more to do.

Case 2: the disk is not properly mounted

Otherwise, the data disk must be mounted.

First, stop all the remaining containers:

docker stop reverse-proxy
docker ps --format '{{.Names}}' > $TMP_DIR/docker-ps-all.txt
cat $TMP_DIR/docker-ps-all.txt | xargs -I '{}' docker stop '{}'

Then mount the data disk to the data folder:

sudo mount -o discard,defaults /dev/sdb /home/curry/data/

And make sure that the disk is now correctly mounted:

lsblk | grep sdb | grep "/home/curry/data"

Then restart all the containers:

cat $TMP_DIR/docker-ps-cardano.txt | xargs -I '{}' docker start '{}'
cat $TMP_DIR/docker-ps-all.txt | xargs -I '{}' docker start '{}'
docker start reverse-proxy

Cleanup

Delete the temporary folder:

rm -rf $TMP_DIR

[jpraynaud]

Cardano transactions prover benchmark

Note

run on GCP with e2-highmem-2 machine with 2 vCPUs and 15GB of RAM
not during Cardano database snapshotting

• Benchmark results:

total_requests	concurrency	transactions/request	requests/s
500	50	1	53.93
500	50	10	39.81
500	50	20	25.17
500	50	30	29.80
500	50	40	23.59
500	50	50	21.11

vs previous results

total_requests	concurrency	transactions/request	requests/s
500	50	1	78.32
500	50	10	53.51
500	50	20	40.93
500	50	30	35.99
500	50	40	23.20
500	50	50	9.94

• Command run:

# Aggregator endpoint
export AGGREGATOR_ENDPOINT=https://aggregator.pre-release-preview.api.mithril.network/aggregator

# Transactions file to prove
export TRANSACTIONS_FILE=transactions-preview.txt

# Transactions proved per request range definition
export TRANSACTIONS_PER_REQUEST_MIN=0
export TRANSACTIONS_PER_REQUEST_MAX=50
export TRANSACTIONS_PER_REQUEST_STEP=10

# Apache benchmark total request sent per benchmark
export AB_TOTAL_REQUESTS=500

# Apache benchmark concurrency level range definition
export AB_CONCURRENCY_MIN=50
export AB_CONCURRENCY_MAX=50
export AB_CONCURRENCY_STEP=50

# Run the benchmark:
./benchmark-aggregator-prover.sh

• Command result:

MITHRIL AGGREGATOR PROVER ROUTE BENCHMARK

>> Aggregator endpoint: https://aggregator.pre-release-preview.api.mithril.network/aggregator
>> Aggregator route: /proof/cardano-transaction
>> Transactions file: transactions-preview.txt
>> Transactions available: [100]
>> Transactions per request range: [0 10 20 30 40 50]
>> AB concurrency range: [50]
>> AB total requests per run: [500]
>> AB total runs: 6
>> Output file: benchmark.csv

>> [#1/6] Running stress test with 500 requests with 1 transactions per request and 50 concurrency
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Finished 500 requests
>>>> Success (78.32 requests/s)

>> [#2/6] Running stress test with 500 requests with 10 transactions per request and 50 concurrency
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Finished 500 requests
>>>> Success (53.51 requests/s)

>> [#3/6] Running stress test with 500 requests with 20 transactions per request and 50 concurrency
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Finished 500 requests
>>>> Success (40.93 requests/s)

>> [#4/6] Running stress test with 500 requests with 30 transactions per request and 50 concurrency
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Finished 500 requests
>>>> Success (35.99 requests/s)

>> [#5/6] Running stress test with 500 requests with 40 transactions per request and 50 concurrency
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Finished 500 requests
>>>> Success (23.20 requests/s)

>> [#6/6] Running stress test with 500 requests with 50 transactions per request and 50 concurrency
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Finished 500 requests
>>>> Success (9.94 requests/s)

>> Benchmark completed:

total_requests,concurrency,transactions/request,requests/s
500,50,1,78.32
500,50,10,53.51
500,50,20,40.93
500,50,30,35.99
500,50,40,23.20
500,50,50,9.94