swcurran
commented
1 year ago We met today to discuss the migration and the following are the notes from the meeting:
- @WadeBarnes will do the bulk of the work and publish progress/expected timings for next steps as notes in this issue.
- @swcurran will ensure that the Delivery team and their contacts are aware of the plans and progress.
- @jleach is the only additional person that we need to do some specific work -- notably pre- and post-migration testing using instances of the Bifold Mobile Verifier against each (dev, test and prod) mediator. @jleach and @WadeBarnes will coordinate directly on the timing, with tasks listed below. @cvarjao -- heads up on this task for @jleach.
The following is the high level plan, the migration steps to be run on each of Dev, Test and Prod, and the tentative timings.
High Level Plan:
- Upgrade the mediator backup container from v13 to v14 -- Dev to Dev Duplicate, Dev, Test and Prod (@WadeBarnes)
- Upgrade Postgres from v10 to v14 - Dev to Dev Duplicate, Dev, Test and Prod. (@WadeBarnes)
- Migrate storage from Indy-SDK to Askar -- Dev Duplicate, Dev, Test and Prod. (@WadeBarnes with help from @jleach)
Everything up to the "Dev Migration" is @WadeBarnes on his own and reporting progress.
Migration Steps:
To be executed for each of Dev, Test and Prod. All tasks are by @WadeBarnes except where @jleach does his part. All but the first step must be done as quickly as is feasible.
- Use two or more mobile verifier instances (on device or simulators) to connect to the pre-migration mediator, connect to each other, and send basic messages to each other. This can be done at any time before the start of the migration. The instances must be preserved for use after the migration (below). @jleach
- Stop mediator service
- Backup database
- Execute Migration
- Start mediator service with Askar
- Use mobile verifier instances from step 1 to verify that they can still send basic messages to one another. @jleach
- If necessary, rollback service (stop mediator service, restore backup, start mediator service with Indy-SDK).
We think that the basic test of two agents that worked before the migration and still work after the migration is sufficient for the transition. Obviously, we will monitor the mediators after each migration and rollback if necessary after more feedback.
Planned Timing
Current plan is as follows -- but this is very much up in the air.
- Dev -- Thursday, April 13 (time TBD between @WadeBarnes and @jleach )
- Test -- Friday, April 14 (time TBD between @WadeBarnes and @jleach )
- Production -- 6AM on Monday, April 17
As @WadeBarnes progresses this week, he'll update the timings as notes on this issue.
The production service MUST go offline at some point, so our plan is to do that before 7AM on some morning next week -- ideally as soon as Monday. We'll give as much notice as possible ahead of time.
Additional Outputs
In addition to the migration, we would like the following additional outputs from the process:
- Documentation and scripts (as make sense) for sharing with others on the migration of a mediator from Indy-SDK to Askar.
- Documentation and scripts (as make sense) for our use and for sharing with others on the migration of any Agent from Indy-SDK to Askar.
esune
WadeBarnes
Devise a plan for the conversion of an Indy SDK ACA-Py deployment to Askar.
We'll need a way to confirm that the conversion worked. For example could the Wallet Team (@cvarjao et al.) define a way to use the BC Wallet to test the conversion? We can test the scalability with the load test tool, but we need to be able to test the upgrade, and the ability of instances of BC Wallet (or other persistent agents) to still be able to use the Mediator after the upgrade.
For example, it might be a good idea to have configured versions of BC Wallet able to use the Dev/Test mediator, and use the Mobile Verifier functionality to create Wallet-to-Wallet connections between them.
Perhaps we could spin up a persistent Traction instance configured to use the mediator such that we can confirm connectivity before and after the conversion. Being able to run chat sessions is sufficient.