Uploaded image for project: 'Okapi'
  1. Okapi
  2. OKAPI-874

install/upgrade: async operation (install jobs) phase 1

    XMLWordPrintable

Details

    • CP: sprint 96, CP: sprint 97, CP: sprint 98
    • 5
    • Core: Platform

    Description

      Implementation ticket based on OKAPI-804

      Purpose

      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.

      Approach

      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.

      Approach

      IPOST with async=true, to install/upgrade will return a Location and the status of the install can be inspected with GET on the returned location.
      DELETE to be used signal "abort" (termination) and remove info about install/upgrade operation.
      When install is working, it will persist status updates in the Okapi DB. 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.

      Implementation proposal
      1. Extend //proxy/tenants/<tenant>/install and //proxy/tenants/<tenant>/install with async=true parameter
      2. Extend https://github.com/folio-org/okapi/blob/master/okapi-core/src/main/raml/TenantModuleDescriptor.json with:
      a. status field: running, done, error
      b. errors array of objects (follow error schema}
      c. Optionally warnings array of objects
      3. Extend https://github.com/folio-org/raml/blob/raml1.0/ramls/tenant.raml with a schema for return body, the schema should include errors, status, warnings which will be merged by Okapi into the combined status response

      TestRail: Results

        Attachments

          Issue Links

            Activity

              People

                adam Adam Dickmeiss
                jakub Jakub Skoczen
                Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                  Created:
                  Updated:
                  Resolved:

                  TestRail: Runs

                    TestRail: Cases