-
Notifications
You must be signed in to change notification settings - Fork 516
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Remove in_memory upgrade set for multi instance upgrading
Signed-off-by: jamshale <[email protected]>
- Loading branch information
Showing
6 changed files
with
38 additions
and
71 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file was deleted.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,50 +1,47 @@ | ||
# Upgrade via API Design | ||
|
||
To isolate an upgrade process and trigger it via API the following pattern was designed to handle multitenant scenarios. It includes a per instance memory singleton and an is_upgrading record in the wallet(DB) and a middleware to prevent requests during the upgrade process. | ||
#### To isolate an upgrade process and trigger it via API the following pattern was designed to handle multitenant scenarios. It includes an is_upgrading record in the wallet(DB) and a middleware to prevent requests during the upgrade process. | ||
|
||
```mermaid | ||
sequenceDiagram | ||
participant A as Agent | ||
participant M as Middleware | ||
participant S as Singleton | ||
participant W as Wallet (DB) | ||
Note over A: Start upgrade | ||
A->>M: POST /any-upgrade-path | ||
M-->>S: check wallet name | ||
S-->>M: | ||
M-->>W: check is_upgrading | ||
W-->>M: | ||
M->>A: OK | ||
A-->>S: add wallet name to set | ||
A-->>W: update is_upgrading = true for wallet or subwallet | ||
Note over A: Attempted Request | ||
A->>M: GET /any-endpoint | ||
M-->>S: check wallet name | ||
S-->>M: | ||
M-->>W: check is_upgrading | ||
W-->>M: | ||
M->>A: 503 Service Unavailable | ||
Note over A: Agent Restart | ||
A-->>W: Get is_upgrading record for wallet or all subwallets | ||
W-->>A: | ||
A-->>S: Populate set with wallet names | ||
A->>A: Resume upgrade if needed | ||
Note over A: Attempted Request | ||
A->>M: GET /any-endpoint | ||
M-->>S: check wallet name | ||
S-->>M: | ||
M-->>W: check is_upgrading | ||
W-->>M: | ||
M->>A: 503 Service Unavailable | ||
Note over A: End upgrade | ||
A-->>S: Remove wallet name from set | ||
A-->>W: delete is_upgrading record for wallet | ||
A-->>W: delete is_upgrading record from wallet | ||
Note over A: Attempted Request | ||
A->>M: GET /any-endpoint | ||
M-->>S: check wallet name | ||
S-->>M: | ||
M-->>W: check is_upgrading | ||
W-->>M: | ||
M->>A: OK | ||
``` | ||
|
||
#### To use this mehanism you simply need to set the upgrading record in the wallet (DB) and add the wallet name to the singleton set. The middleware will prevent requests from being processed until the upgrade process is finished. After the upgrade process is finished you must remove the wallet name from the set and delete the upgrading record in the wallet (DB). | ||
#### To use this mehanism you simply need to set the upgrading record in the wallet (DB). The middleware will prevent requests from being processed until the upgrade process is finished. After the upgrade process is finished you must remove the upgrading record in the wallet (DB). | ||
|
||
##### An example can be found via the anoncreds upgrade `aries_cloudagent/wallet/routes.py` in the `upgrade_anoncreds` controller. |