automated test coverage of functionality after Pismo -> Vaults upgrade

[turadg]

What is the Problem Being Solved?

Description of the Design

Use #7499

• 1. Start a new Pismo chain

• 2. Do a handful of transactions to get state to preserve

• Has to be all the state we care about checking

• Provision wallets

• Have Cosmos/vbank balances

• Change governance parameters

• EC purses with invitations (to make sure it doesn’t break anything when it’s no longer present)

• 3. Swapping out the binary

• 4. Do the upgrade

• 5. Check that the state from transactions is still present

• e..g provisioned wallets are restored

• 7. Check EC restore

• They can accept fresh invitations

• Change parameters

• 8. PSM functionality

• Trade again. Vbank updates

• 9. Metrics (to be added in Provisionpool Metrics aren't retained across vaults upgrade #7705)

• Contract metrics are retained after upgrade

• 10. Provision pool balance

Use https://github.com/Agoric/docker-upgrade-test/tree/main/upgrade-test-scripts to make a new upgrade handler.
It includes gov1,gov2,gov3 accounts.
Use agoric and agops CLI commands in the scripts, as an end user could. Maybe adapt https://github.com/Agoric/agoric-sdk/blob/master/packages/agoric-cli/test/agops-vaults-smoketest.sh

Consider adapting the bootstrapTests which specify behavior and expected results.

Security Considerations

Scaling Considerations

Test Plan

• Verify that product works with realistic state after restart of all vats
• Cover the Inter Protocol User Stories

[raphdev]

Add a test in https://github.com/Agoric/docker-upgrade-test/blob/main/Dockerfile that triggers a CORE_EVAL proposal (V+1 is just a contract upload and a CORE_EVAL, approved by BLD Stakers but not validators)

This sounds like Vaults -> V + 1 upgrade, while this issue describes mostly Pismo -> Vaults upgrade. Is this in scope? If it isn't we should track separately.

[turadg]

This sounds like Vaults -> V + 1 upgrade, while this issue describes mostly Pismo -> Vaults upgrade. Is this in scope? If it isn't we should track separately.

I'll edit the test plan of this. We do have coverage of testing the V --> V+1 upgrade ability:

• feat: test restarting all PSM instances #7698
• test(deployment): end-to-end test of on-chain contract upgrade #7691
• 7562 proposal restart #7660

Per our discussion with @arirubinstein yesterday IIUC we wouldn't want that to go in upgrade-test system because it's not an actual upgrade. With something like #7725 we could get the above into Docker upgrade-test without making recording it as an upgrade.