Verify Traction plugin can run alongside other Aca-Py plugins

[esune]

As an Aca-Py plugin, Traction should be able to run alongside other plugins (such as the issuer registration plugin for Aries VCR).

In order to assess next steps for standing-up an Aries VCR/OrgBook issuer agency (see this) we need to be reasonably sure other plugins will be able to work alongside Traction.

[ianco]

I've opened 2 draft PR's:

traction - includes the orgbook plugin in the traction build - https://github.com/bcgov/traction/pull/424 aries-vcr issuer - updated to use a traction tenant as orgbook issuer - https://github.com/bcgov/aries-vcr-issuer-controller/pull/74

Both are in draft due to some outstanding issues/questions, but demonstrate that traction can be used as an orgbook issuer

[ianco]

Some items we need to address in traction:

• use of the ADMIN_API_KEY - we shouldn't give this to tenants
• configuration of webhooks - I currently need to call the multitenant API directly
• use of proxy - I didn't use this for the aries-vcr issuer so not sure of the requirements, configuration etc.
• how to install plug-ins - pip vs poetry

[esune]

@usingtechnology are you able to provide insight on items 1, 2 and 4? I believe item number 3 is addressed by #439 at least at the API level: @loneil I can't find the UI/UX ticket for this issue, would you mind adding it here for reference?

[usingtechnology]

1. Use of ADMIN_API_KEY. We deploy traction with a proxy of the admin API that hides the ADMIN_API_KEY, so tenants do not have to set it or know it. They simply need their token. The proxy is a work in progress, it makes some functions (such as multitenancy wallet calls - except token; startup/shutdown, etc) unreachable. All tenants (including the innkeeper - which is a tenant) go through the proxy, never the admin API.
2. webhooks are added and available for tenants to manage their own. See PR 439. The shapes of the calls and responses are identical to the multitenancy wallet GET / PUT that an admin used to call on behalf of a tenant.
3. not sure what this is about exactly. if the wallet/agent used by aries VCR is a traction agent, then it should be going through the proxy. So if it requires some functions that are unavailable, we should discuss. particularly if it was doing both admin calls (no Authorization Bearer token, just API_ADMIN_KEY) and "tenant" calls.
4. still up in the air, but I think having a plugin delivered with requirements.txt for pip is probably best, poetry can export a requirements.txt file, so it could sit beside pyproject.toml.

[loneil]

The FE for setting the webhooks is https://github.com/bcgov/traction/issues/448

[esune]

@usingtechnology I think 1 and 3 are related. I will try and catch-up with @ianco about what we need exactly. The Aries VCR agents would not be making calls that would require the ADMIN_API_KEY so we should be good. I will start poking at things.

I'm leaning myself towards using pip and not adding extra dependencies to the toolchain unless extremely necessary: what changes are necessary to have pip as default package manager?

[usingtechnology]

I don't think any... assuming building onto von-image. poetry was used simply because almost all of the other plugins were using that as the dependency manager. but as I said, I think devs can use poetry for their work, but just export the requirements and leave that alongside their code and it should work nicely. better to go that route than make devs use poetry and have a pyproject.toml/lock file(s).

[ianco]

I updated this plugin to remove the issuer registration plug-in, and install from github (aries-vcr repo).

I've added the poetry config file to the plug-in in the aries-vcr repo (https://github.com/bcgov/aries-vcr/pull/737) so the plug-in can be installed using pip or poetry.

[esune]

I think we can consider this issue done. I will log an issue in the aries-vcr-issuer-controller repo to track the changes required to run in traction mode.

The pr in Aries VCR @ianco submitted makes it possible to install the issuer-registration plugin alongside the traction plugin: I do not think we need changes to the traction repo to include the plugin by default, it would be a capability that is added at build time, if required.