Upgrade ACA-Py Agents

[WadeBarnes]

These upgrades should be performed in combination with https://github.com/bcgov/DITP-DevOps/issues/83

The DITP Inventory of Deployments contains a list of our deployed ACA-Py agents. Review the list and upgrade the agents to the latest ACA-Py version. Endorser agents running 1.0.0-rcx versions may need special attention, as they were deployed before full support for the endorser protocols were officially released with ACA-Py.

Where possible the spreadsheet contains links to the agent's deployment within OCP.

The data in the spreadsheet is generated in part by an automated audit script that scans the OCP environments for agent instances and collects data including agent version, secure storage type, and endorser role; docs. getDids.sh

Note: - ACA-Py 0.12.0rc0 resolves the issues with routing of REVOC_REG_ENTRYs through an Endorser. Test results here; https://github.com/hyperledger/aries-cloudagent-python/issues/2441#issuecomment-1921696128

Next Steps:

• [ ] Now that we have a solution for the REVOC_REG_ENTRY routing issue. Start breaking down the issuer-kit based agents and outline what's involved with upgrading each. Expected to be involved are indy to askar migrations, wallet database upgrades (to Postgres v14 as that is the easiest target), and migration to askar only images. This work should be performed in separate tickets, one top level one to better identify the affected agents, and possibly additional tickets for each of the more involved upgrades. Priority should be given to active issuers that are affected by the REVOC_REG_ENTRY routing issues.

Below is a list of repositories containing references to ACA-Py images:

• [ ] https://github.com/bcgov/trust-over-ip-configurations
  • There are a mix of agents from aca-py v0.7.4 to aca-py v0.10.3 in the Digital Trust Services Trust Over IP (e79518) environments. They all need to be brought up to the same version. Which requires indy to askar migration in some cases.
• [x] https://github.com/bcgov/issuer-kit
  • Used mostly for bcgov/trust-over-ip-configurations. There are a mix of agents from aca-py v0.7.4 to aca-py v0.10.3 in the Digital Trust Services Trust Over IP (e79518) environments. They all need to be brought up to the same version.
• [ ] https://github.com/bcgov/aries-vcr
  • Blocked by the issues here. Attempts were made to upgrade to aca-py v0.11.0 and aca-py v0.10.5. Neither version worked with BC Reg and OrgBook.
• [ ] https://github.com/bcgov/orgbook-configurations
  • Blocked by the issues here. Attempts were made to upgrade to aca-py v0.11.0 and aca-py v0.10.5. Neither version worked with BC Reg and OrgBook.
• [ ] https://github.com/bcgov/von-bc-registries-agent
  • Blocked by the issues here. Attempts were made to upgrade to aca-py v0.11.0 and aca-py v0.10.5. Neither version worked with BC Reg and OrgBook.
• [ ] https://github.com/bcgov/von-bc-registries-agent-configurations
  • Blocked by the issues here. Attempts were made to upgrade to aca-py v0.11.0 and aca-py v0.10.5. Neither version worked with BC Reg and OrgBook.
• [x] ~https://github.com/bcgov/iiwbook~
• [x] ~https://github.com/bcgov/indy-email-verification~
  • [x] Frozen, repo marked with Dormant life cycle badge.
• [x] https://github.com/bcgov/vc-authn-oidc
• [x] ~https://github.com/bcgov/dts-vc-issuer-service~
  • [x] Archive
• [x] ~https://github.com/bcgov/aries-vcr-issuer-agency~
  • [x] Archive
• [x] ~https://github.com/bcgov/moh-prime~
  • They have commented out the reference to the old aca-py image.
• [x] ~https://github.com/bcgov/moh-vvc-issuer~
  • [x] Freeze
  • [x] Submitted a request to archive the repo; https://github.com/bcgov/moh-vvc-issuer/issues/9
• [x] ~https://github.com/bcgov/dts-vc-tutorial~
• [x] ~https://github.com/bcgov/healthgateway~
  • They have removed the references to aca-py.
• [x] ~https://github.com/bcgov/essential-services-delivery~
• [x] ~https://github.com/bcgov/identity-kit-configurations~
  • [x] Archive
• [x] ~https://github.com/bcgov/ised-business-banking-initiative~
• [x] ~https://github.com/bcgov/aries-acapy-plugin-redis-events~
• [x] https://github.com/bcgov/traction

[WadeBarnes]

We'd like to automate the detection and upgrade process, @jleach do you have any thoughts and references we could use? My first thoughts are something like the bcgov/repomountie bot.

[jleach]

Could take the API work from repomountie and make a cron job. The bots a mostly event driven so not awesome at looking through repos for outdated data.

Could troll repos and create a PR for the update.

[WadeBarnes]

There is an issue with revocation notifications that has been identified and confirmed in aca-py v0.7.5 so it's no longer in the upgrade path. We'll have to upgrade to a newer release. The only other available at the moment is v1.0.0-rc0 which is being used for LSBC.

[WadeBarnes]

The NR FSA team uses Dependabot and Renovate to keep their various dependencies up to date. We should look further into these tools as well.

[swcurran]

Renovate is a new one to me — https://github.com/renovatebot/renovate. What is the difference between it and dependabot? And aren’t we already using dependabot everywhere?

[WadeBarnes]

I don't know how they compare yet, but how they are used is different than simply using dependabot to get updates for security vulnerabilities. They are using them to get updates to their dependencies when new versions are released, regardless of whether the release is associated with a security vulnerability.

[swcurran]

Got it. That’s good. Especially if the PRs get automatically run through the unit/integration tests. Would that be enough for merges? Where does the dev judgement (and time…the harder part) come in.

[WadeBarnes]

I'd think we'd want the devs to review the related release's changes to determine if it contains anything problematic for the given implementation. Some of the projects in the list above are marked for archiving so the list will get smaller, but I doubt all of the remaining projects have tests running against their aca-py integration, so it's going to require a project by project call.

It's more of a matter of automating the detection and updates, since we typically update all of our projects at once, once we've done some preliminary testing with one of them.

[WadeBarnes]

First step to a new official release; https://github.com/hyperledger/aries-cloudagent-python/releases/tag/0.8.0-rc0

[WadeBarnes]

Official release; https://github.com/hyperledger/aries-cloudagent-python/releases/tag/0.8.1

[WadeBarnes]

Official release; https://github.com/hyperledger/aries-cloudagent-python/releases/tag/0.8.2

[esune]

@WadeBarnes I think we should re-assess which agents we want to update vs. which agents should be "frozen" since the projects they belong to are either archived/frozen or unmaintained at this point.

[WadeBarnes]

@esune, Updated the list in the description. Please review and see if you agree with the ones I've marked freeze and/or archive. Not sure what we should do with the moh and health gateway ones.

[esune]

@esune, Updated the list in the description. Please review and see if you agree with the ones I've marked freeze and/or archive. Not sure what we should do with the moh and health gateway ones.

What you are proposing makes sense to me. I am wondering if we should open issues to remove references for moh and health-gateway (or a PR doing so, potentially?) and leave it to the code owners to take action in their repositories?

[WadeBarnes]

I am wondering if we should open issues to remove references for moh and health-gateway (or a PR doing so, potentially?) and leave it to the code owners to take action in their repositories?

That seems appropriate.

[WadeBarnes]

Updated and reorganized the list of updates to be made in the description.

[WadeBarnes]

Updated the DITP Inventory of Deployments spreadsheet with a new tab labeled 2024.01.19.

[esune]

Updated the DITP Inventory of Deployments spreadsheet with a new tab labeled 2024.01.19.

Thanks @WadeBarnes . I noticed there are remnants of an old (decommissioned) endorser deployment, logged https://github.com/bcgov/DITP-DevOps/issues/156 to take care of that.

[esune]

We also might need to track https://github.com/bcgov/aries-vcr-issuer-controller for updates, since some of the deployed OrgBook integrations use it for their source code.

[esune]

IDIM dev agent to be completed this week. Testing and follow-up upgrade of remaining environments to be planned once change is validated.

[WadeBarnes]

IDIM dev agent to be completed this week. Testing and follow-up upgrade of remaining environments to be planned once change is validated.

Complete. IDIM dev has been upgraded to ghcr.io/hyperledger/aries-cloudagent-python:py3.9-0.12.2.