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

SPIKE: consider async tenant install/upgrade



    • New Feature
    • Status: Closed (View Workflow)
    • P2
    • Resolution: Done
    • None
    • None
    • CP: sprint 86, CP: sprint 87, CP: sprint 84, CP: sprint 85, CP: sprint 88, CP: sprint 89, CP: sprint 90, CP: sprint 91, CP: sprint 92, CP: sprint 94, CP: sprint 95, CP: sprint 96, CP: sprint 97, CP: sprint 98, CP: sprint 99, CP: sprint 100
    • Core: Platform


      Module prepare/upgrade may take a long time and thus, make the install/upgrade service take a long time.. Multiple hours in some cases.. Consider whether to make the install/upgrade async .. For example – return immediately – after immediate checks are done.. and let it run in the background.. The Okapi is OK that tenant init to individual modules take time.. But client software (ore reverse proxies in between) using Okapi may not be.


      To remain backwards compatible with existing modules we could retain sync API for the the tenant "init" and provide an async "install/upgrade" facade endpoint in Okapi This will prevent timeouts cause by reverse proxies or clients shutting down connections.

      When invoked, Okapi will do only immediate checks and return a


      header with an URI to the status endpoint that the client can poll subsequently to check progress.

      The "status" endpoint will contain the information about the upgrade/migration status (or error if failure encountered) for each module.

      See more at https://wiki.folio.org/display/FOLIJET/Async+install

      TestRail: Results


          Issue Links



                adam Adam Dickmeiss
                adam Adam Dickmeiss
                0 Vote for this issue
                6 Start watching this issue



                  TestRail: Runs

                    TestRail: Cases