OKAPI-804 - Getting issue details... STATUS
The purpose of the async install is to address the problem of long tenant init operations. While Okapi's HTTP client has no timeout for that operation, there are clients using Okapi and/or gateways between Okapi and a backend module which causes trouble and might give up on such long operations. The async install will only deal with the former problem. The latter problem will have to make each module work in an async fashion or use some other means of transport.
To address this, and also to be able to monitor the progress of an install which may be calling tenant for multiple modules, it would be good to "persist" the operation.
The install and the upgrade (/_/proxy/tenants/<tenant>/install and /_/proxy/tenants/<tenant>/upgrade) .. can be kept as they are with no changes to existing behavior. They are currently using POST to perform the operation. We'd like to do use the same method to initiate the async operation. It could be as simple as using a flag "async=true" as query parameter. The RAML definition will be "identical" for non-async and sync mode.. But of course what follows is "async" only.
If async=true, install/upgrade will return a Location and the status of the install can be inspected with GET on the returned location. It could be extended with DELETE to signal "abort" and remove info about install/upgrade operation.
When install is working, it will persist. It should also persist after it's done - as far as calling module's tenant init. It could persist as long as Okapi is running (for the cluster).. and be removed when Okapi/cluster is removed.
To list all operations, since the cluster was started .. it would be possible to use GET on the install/upgrade path.. same as POST to initiate. Likewise DELETE on that path would remove info for all operations.
It does not seem necessary to persist this to a database.. But it could be done.. And so list all install/upgrade operations ..
The status format .. could be an extension of the TenantModuleDescriptor.json format with an addition of a status: pending, working, done, failed.