add test for upgrade polkadot version in node

[pepoviola]

POC: Add upgrade node test. (see https://github.com/paritytech/polkadot/issues/5172) cc @chevdor, this is something like we talk last time?

Thanks!

[chevdor]

cc @EgorPopelyaev: this is something we were missing.

[sandreim]

Thanks @pepoviola . This looks heading to the right direction, but the actual test should live in the polkadot repo under the misc folder. Additionally, it should be able to determine the last release version and start with that, then after doing some work and populating the DB it should switch the client binary to the one from the PR artifacts. Testing both rocksDB and parityDB at same time (2 nodes) would be awesome.

[pepoviola]

Thanks @pepoviola . This looks heading to the right direction, but the actual test should live in the polkadot repo under the misc folder. Additionally, it should be able to determine the last release version and start with that, then after doing some work and populating the DB it should switch the client binary to the one from the PR artifacts. Testing both rocksDB and parityDB at same time (2 nodes) would be awesome.

Hi @sandreim, sounds good. We can start the nodes with the image from parity/polkadot:latest (the registry were we publish the releases). What do you have in mind to populate the DB?

Thanks!

[ordian]

anything blocking this?

[pepoviola]

anything blocking this?

No, the feature is already working in zombienet. I can write a test in polkadot repo, did you have a list changes to make in the db before running the upgrade?

Thanks!

[sandreim]

@pepoviola i think just letting it run for 2-3 sessions with 2 paras should populate the db enough for a PR CI test. @ordian do you think this is enough?

[ordian]

@pepoviola i think just letting it run for 2-3 sessions with 2 paras should populate the db enough for a PR CI test. @ordian do you think this is enough?

We discussed the test scenario in DMs. But I think we don't need to wait for 2-3 sessions for this, just produce and import a few blocks. The main point to test if we can open the db from the new version to check if there any breaking changes to the db layout.

[sandreim]

So, no reason to go deeper than the layout?, I was thinking it is worth to also catch breaking changes at the content level - decoding a value fails.

[ordian]

I was thinking it is worth to also catch breaking changes at the content level - decoding a value fails.

I don't think we need to go for more than a few blocks (+ maybe a dispute) to catch this.