Skip to content

Latest commit

 

History

History
66 lines (39 loc) · 3.79 KB

unwanted-modules.md

File metadata and controls

66 lines (39 loc) · 3.79 KB

Disabling and undeploying unwanted FOLIO modules

Background

FOLIO is big. Really big. If you're working on developing a module for it, you are likely running against a virtual machine managed by Vagrant -- but such VMs now need a great deal of memory. For example, mod-copycat uses enough FOLIO backend modules that it can't run against the folio/core Vagrant box, and needs folio/testing, which needs more than 10 Gb RAM if it is to avoid an orgy of paging that will render the host box all but unusable.

So to reduce the in-memory size of FOLIO, we want to identify modules that we know we don't need and shut them down.

This is a multi-stage process:

In the development scenario, there is almost always only a single tenant in play, diku, so we will make that simplifying assumption in this document. To make the examples concrete, we will also assume that Okapi is running on localhost port 9130.

1. Identify the modules currently running

You can find these at http://localhost:9130/_/discovery/modules but the output is very verbose. You can pick out the service-IDs, which are the only parts you need, using jq:

curl http://localhost:9130/_/discovery/modules | jq '.[].srvcId'

2. Choose the ones that are not wanted

For example, if you are working on the single-record copy-cataloguing facilities provided by mod-copycat, then you certainly need to retain mod-inventory, but mod-email is not likely to be of interest, and mod-circulation may not be needed.

3. Check that disabling will not have catastrophic consequences

In the next step, we are going to disable a named module together with all other modules that depend on it (or, more precisely, on interfaces that it provides), and the module that depend on those, and so on. By first running that step with a simulate=true query, we can see the full list of modules that will be disabled:

curl -X POST http://localhost:9130/_/proxy/tenants/diku/install?simulate=true -d '[{"id":"mod-circulation","action":"disable"}]'
[ {
  "id" : "mod-orders-11.2.0-SNAPSHOT.376",
  "action" : "disable"
}, {
  "id" : "mod-ncip-1.6.4-SNAPSHOT.31",
  "action" : "disable"
}, {
  "id" : "mod-circulation-19.3.0-SNAPSHOT.790",
  "action" : "disable"
} ]

If this cascade results in the removal of modules that are needed, then a rethink is called for.

4. Disable these modules (and those that depend on them)

If you are happy with the cascade, go ahead and disable the module:

curl -X POST http://localhost:9130/_/proxy/tenants/diku/install -d '[{"id":"mod-circulation","action":"disable"}]'

5. Undeploy those modules including those that depend on them

The module and its dependents are now disabled for the diku tenant, but are still running and consuming resources. To undeploy them, it is necessary to DELETE them from /_/discovery/modules using the id fields reported by the disable response:

curl -X DELETE http://localhost:9130/_/discovery/modules/mod-orders-11.2.0-SNAPSHOT.376
curl -X DELETE http://localhost:9130/_/discovery/modules/mod-ncip-1.6.4-SNAPSHOT.31
curl -X DELETE http://localhost:9130/_/discovery/modules/mod-circulation-19.3.0-SNAPSHOT.790