[MXS-3849] Unable to configure nested parameters via MaxCtrl Created: 2021-11-03  Updated: 2022-01-13  Resolved: 2021-11-19

Status: Closed
Project: MariaDB MaxScale
Component/s: maxctrl
Affects Version/s: 6.1.4
Fix Version/s: 6.2.0

Type: Bug Priority: Minor
Reporter: Assen Totin (Inactive) Assignee: markus makela
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Relates
relates to MXS-3883 nosqlprotocol parameters are not seri... Closed

 Description   

MaxCtrl wrongly interprets nosqlprotocol.user my_user as the following JSON:

{ "nosqlprotocol.user": "my_user" }

it should interpret it as a nested type:

{ "nosqlprotocol": { "user": "my_user" } }

The inability to modify nosqlprotocol parameters is a separate problem tracked in MXS-3883.

Original description:

Our KB explains that the NoSQL listener must have certain protocol-speicific parameters explicitly configured -for example, username and password for the backend that will be used by all connections, coming to this listener:

https://mariadb.com/kb/en/mariadb-maxscale-6-nosql-protocol-module/#parameters

This works for static configuration, but not for dynamic one via maxctrl:

[root@s4name assen.totin]# maxctrl alter listener mcs_mongo  nosqlprotocol.user mongo_test
 
Error: Server at http://127.0.0.1:8989 responded with 403 Forbidden to `PATCH listeners/mcs_mongo`
 
{
 
    "errors": [
 
        {
 
            "detail": "listener: The parameter 'nosqlprotocol.user' is unrecognized."
 
        }
 
    ]
 
}

The listener itself before patching:

[root@s4name assen.totin]# maxctrl show listeners
 
┌────────────┬───────────────────────────────────────────┐
 
│ Name       │ mcs_mongo                                 │
 
├────────────┼───────────────────────────────────────────┤
 
│ Service    │ mcs_service                               │
 
├────────────┼───────────────────────────────────────────┤
 
│ Parameters │ {                                         │
 
│            │     "address": "::",                      │
 
│            │     "authenticator": null,                │
 
│            │     "authenticator_options": null,        │
 
│            │     "connection_init_sql_file": null,     │
 
│            │     "port": 27017,                        │
 
│            │     "protocol": "nosqlprotocol",          │
 
│            │     "service": "mcs_service",             │
 
│            │     "socket": null,                       │
 
│            │     "sql_mode": "default",                │
 
│            │     "ssl": false,                         │
 
│            │     "ssl_ca_cert": null,                  │
 
│            │     "ssl_cert": null,                     │
 
│            │     "ssl_cert_verify_depth": 9,           │
 
│            │     "ssl_cipher": null,                   │
 
│            │     "ssl_crl": null,                      │
 
│            │     "ssl_key": null,                      │
 
│            │     "ssl_verify_peer_certificate": false, │
 
│            │     "ssl_verify_peer_host": false,        │
 
│            │     "ssl_version": "MAX",                 │
 
│            │     "type": "listener"                    │
 
│            │ }                                         │
 
└────────────┴───────────────────────────────────────────┘

MaxScale version:

[root@s4name assen.totin]# rpm -q maxscale
 
maxscale-6.1.4-1.rhel.7.x86_64



 Comments   
Comment by markus makela [ 2021-11-03 ]

As a workaround, you can destroy and recreate the listener to reconfigure it.

Comment by markus makela [ 2021-11-16 ]

There's two parts to this problem: the problem of the parameter not being detected and the fact that nosqlprotocol doesn't currently support modification of parameters at runtime.

Comment by Assen Totin (Inactive) [ 2021-11-16 ]

Maybe update the KB at least then, until it becomes feasible to implement dynamic config?

My impression from MaxScale modules, which may well be wrong, was that pretty much everything in their config can be change on-the-fly. Would be nice to ave exceptions outlined in the docs, to avoid confution.

Comment by markus makela [ 2021-11-16 ]

Yup, we can definitely do that.

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