unit icon indicating copy to clipboard operation
unit copied to clipboard

Query control API to show the loaded modules

Open lcrilly opened this issue 7 months ago • 8 comments

This feature extends the /status Control API endpoint to include the currently loaded modules.

Currently, the available modules are loaded by the discovery process at startup and logged to the Unit log file.

2024/06/26 09:36:16 [info] 55991#2488927 discovery started
2024/06/26 09:36:16 [notice] 55991#2488927 module: php 8.3.4 "/var/lib/unit/modules/php.unit.so"
2024/06/26 09:36:16 [notice] 55991#2488927 module: python 3.12.2 "/var/lib/unit/modules/python3.unit.so"
2024/06/26 09:36:16 [notice] 55991#2488927 module: wasm-wasi-component 0.1 "/var/lib/unit/modules/wasm_wasi_component.unit.so"
2024/06/26 09:36:17 [info] 55990#2488925 controller started

This information is already transferred to the Control API because attempts to configure an application with an unloaded "type" fails with a suitable error, e.g.

$ echo '{"bogus":{"type":"cobol"}}' | unitc /config/applications
{
  "error": "Invalid configuration.",
  "detail": "The module to run \"cobol\" is not found among the available application modules."
}

It would be much more convenient if the loaded modules information was also queryable at runtime. So the /status endpoint would return something like:

{
  "modules": [
    "php 8.3.4",
    "python 3.12.2",
    "wasm-wasi-component 0.1"
  ],
  "connections": { … },
  "requests": { … },
  "applications": { … }
}

This would provide a more convenient way of checking what language modules are loaded. It would also benefit command line tools that auto-configure Unit to serve applications.

lcrilly avatar Jun 26 '24 15:06 lcrilly