[MXS-4541] Provide a way to show details about all supported MaxScale modules via REST API and/or MaxCtrl Created: 2023-03-03  Updated: 2023-06-27  Resolved: 2023-06-27

Status: Closed
Project: MariaDB MaxScale
Component/s: maxctrl, Plugin, REST-API
Affects Version/s: 2.4, 2.5, 6.4, 22.08, 23.02
Fix Version/s: 2.5.27, 6.4.8, 22.08.7, 23.02.3

Type: New Feature Priority: Major
Reporter: Geoff Montee (Inactive) Assignee: markus makela
Resolution: Fixed Votes: 0
Labels: None

Sprint: MXS-SPRINT-185

 Description   

MaxScale currently provides MaxCtrl commands and REST API endpoints to view details about MaxScale modules. However, these commands and endpoints only currently return details about modules that are currently in use. This applies to:

  • The maxctrl list modules command
  • The maxctrl show modules command
  • The corresponding REST API endpoints

It would be great if MaxScale could provide a MaxCtrl command and/or REST API endpoint to view details about all supported modules--not just the modules that are currently in use. The Documentation Team would be able to use functionality like this to programmatically determine which modules are supported by a specific version of MaxScale.

Steps to reproduce

1. Configure MaxScale using the procedure on this page.

2. Start the MaxScale services:

$ maxctrl start services

3. List the modules:

$ maxctrl list modules

Actual results

The output only shows the modules that are configured:

┌─────────────────┬─────────────────┬─────────┐
│ Module          │ Type            │ Version │
├─────────────────┼─────────────────┼─────────┤
│ maxscale        │ maxscale        │ 6.2.4   │
├─────────────────┼─────────────────┼─────────┤
│ servers         │ servers         │ 6.2.4   │
├─────────────────┼─────────────────┼─────────┤
│ MariaDBAuth     │ Authenticator   │ V2.1.0  │
├─────────────────┼─────────────────┼─────────┤
│ mariadbmon      │ Monitor         │ V1.5.0  │
├─────────────────┼─────────────────┼─────────┤
│ MariaDBProtocol │ Protocol        │ V1.1.0  │
├─────────────────┼─────────────────┼─────────┤
│ PAMAuth         │ Authenticator   │ V1.0.0  │
├─────────────────┼─────────────────┼─────────┤
│ qc_sqlite       │ QueryClassifier │ V1.0.0  │
├─────────────────┼─────────────────┼─────────┤
│ readwritesplit  │ Router          │ V1.1.0  │
└─────────────────┴─────────────────┴─────────┘

Expected results

The actual output is missing the modules that are not currently in use, including:

  • gssapiauth Authenticator
  • readconnroute Router
  • binlogrouter Router
  • xpandmon Monitor
  • And many more

It would be great if MaxScale supported some way to obtain details about all supported modules.



 Comments   
Comment by markus makela [ 2023-03-03 ]

You can force MaxScale to load all modules with the load=all option on the /v1/maxscale/modules endpoint (documentation). It's what the GUI uses to provide the parameter information and the endpoint is also in all the currently supported versions.

Comment by Geoff Montee (Inactive) [ 2023-03-03 ]

Thanks! Does maxctrl list modules and/or maxctrl show modules have a way to set load=all, or do you have to use the raw REST API?

Comment by markus makela [ 2023-03-03 ]

No, you'll have to do that directly on the REST-API.

Comment by markus makela [ 2023-03-07 ]

GeoffMontee Since this is already implemented for the API and the GUI already displays it, do you think that a separate new feature is required for MaxCtrl or is a raw REST-API call sufficient for your needs? Loading all modules automatically is not something one would want to do since it will increase the amount of memory MaxScale uses with no way to unload the modules.

Comment by Geoff Montee (Inactive) [ 2023-03-07 ]

Hi markus makela,

In my opinion, it would be great for MaxCtrl to support this functionality as well. I understand that it would probably not be good to have this as default behavior, but what about as an option? Maybe something like this?:

$ maxctrl list modules load=all

or this?:

$ maxctrl list modules --load-all

Comment by markus makela [ 2023-03-07 ]

A --load-all option seems like a reasonable approach and it would be consistent with how other "custom" operations (e.g. maxctrl set server --force) behave.

Generated at Thu Feb 08 04:29:23 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.