-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migrate LSBC issuer to use Aries Askar and the Shared Components #83
Comments
Heads up on this @i5okie, @WadeBarnes and @esune. We should discuss the challenges in doing this, and the tools available to help with this process. |
I've updated the google spreadsheet with the agent version and storage type information, which will make this easier. We currently have 33 aca-py instances using indy and another 29 instances using askar |
Migrating to askar should be performed at the same time as an agent and wallet upgrade. When performing these steps it is extremally important to ensure the upgrades and updates are being done to a single ACA-Py instance at a time. This typically means, at least temporarily, isolating the image tags used by the deployment configuration to ensure the single instance is targeted when new images are deployed. For example the deployment configuration templates for the agents and wallets in bcgov/trust-over-ip-configurations have been specifically designed for this purpose.
Steps:
I have a checklist template for this started in the DITP-DevOps repo, but I have not checked it in yet. |
Refer to #18 for a link to the spreadsheet listing the agent deployments and their associated storage type. |
Looks like IDIM is already using Askar, so the focus is only on the migration of LSBC. Propose making this task ONLY about the migration of LSBC, and we open new tasks for the migration of other deployments. |
Updated the title of the ticket and description to talk only about LSBC. We need to be ready to upgrade the LSBC issuer to a new version of ACA-Py when it becomes available, which will have fixes that are only available using Askar. |
Migrate to using Askar only images at the same time. |
LSBC
|
I plan to switch the migrated instances to the Askar only images and rotate the registries once the official ACA-Py |
LSBC I rotated the RevRegs twice as a test, since the rotate only generated a single RevReg. First rotation:
Decommissioned:
Second rotation:
Decommissioned:
@usingtechnology, can you confirm this behavior would be due to only having a single RevReg active to start with. I forgot to double check before I rotated. |
LSBC State Before Rotation:
Full:
State After Rotation:
Decommissioned:
@usingtechnology, These results confirm the rotate is only creating new RevRegs for |
Are you fetching results with Long story short - yes. For each Active registry being rotated out a new one is created/activated. If there is only one then only one will replace it. The list of decommissioned can appear larger than expected because every call to rotate will mark ALL (except init state) as decommissioned - so the currently active plus: generated, posted, and full. |
Yes, and filtered by the cred_def_id. |
Notified LSBC that the updates are complete for |
LSBC State Before Rotation:
State After Rotation:
Decommissioned:
|
Updated: Changed to be specific to the LSBC Issuer. This is a precursor task to updating the LSBC Issuer to a soon-to-be-released version of ACA-Py.
Dev
UUHA3oknprvKrpa7a6sncK:3:CL:209518:default
Test
AuJrigKQGRLJajKAebTgWu:3:CL:209526:default
Prod
4xE68b6S5VRFrKMMG1U95M:3:CL:59232:default
Related tickets:
Tagged Upgrade Command:
v0.5.2
] openwallet-foundation/acapy#2486The text was updated successfully, but these errors were encountered: