install/upgrade: tenant API extensions (phase2)
Description
Environment
Potential Workaround
is blocked by
relates to
Checklist
hideTestRail: Results
Activity
Marc Johnson December 10, 2020 at 11:27 AMEdited
I have found a (serious) problem with the Async API design / implementation. It probably won't work with a load balancer between Okapi and modules(s). The RMB implementation assumes the same instance is consulted during the tenant operation.
As noted by on Slack, it cannot be guaranteed that Okapi will be making the request for job status to the same instance of the module as initiated the upgrade job. And that [RMB-772] was raised in response to that, to make RAML Module Builder modules have shared state for upgrade jobs.
Is this is general expectation for all modules that implement Tenant API version 2.0?
If it is, what would folks suggest for modules that have no persistent storage of their own yet do perform upgrade steps (e.g. mod-circulation which registers itself with pub-sub)?
Is it is expected that all modules will use Tenant API 2.0 in the 2021 R1 official distribution of FOLIO?
cc:
Marc Johnson December 10, 2020 at 10:56 AM
Opposite: Okapi reports error if module returns Location and provides 1.1 / 1.2 (ModuleDescriptor not updated)
Ah, thank you for clarifying that. Does that mean it is legitimate for the Tenant API 2.0 to perform an upgrade either synchronously or asynchronously?
Adam Dickmeiss December 10, 2020 at 8:12 AM
On the full Location.. Okapi does not obey that. Which could be a problem.
Adam Dickmeiss December 10, 2020 at 8:12 AM
Opposite: Okapi reports error if module returns Location and provides 1.1 / 1.2 (ModuleDescriptor not updated)
Marc Johnson December 9, 2020 at 2:04 PM
If a module says "2.0", but return 200 and no Location, Okapi will think it is synchronous
I thought following the conversation on the pull request Okapi was going to fail the upgrade process in this case?
Details
Details
Assignee
Adam DickmeissReporter
Jakub SkoczenLabels
Priority
P2
Implementation ticket based on
This is the phase 2 that introduced async tenant init API between Okapi and modules. This is to avoid timeouts for long running connections that may be timed out by LBs.
The API will work similarly to OKAPI-874:
POST will create an "init job" that can be subsequently polled by Okapi (or another client) to collect status information.
DELETE (stopping the "init job") is not part of initial implementation
Default RMB implementation for the new async API is RMB-754