Ensure cluster-wide parameters mechanism correctness (when working with query settings parameter) (SERVER-78801)

[SERVER-78804] Prevent setClusterParameters being called on querySettings parameter Created: 10/Jul/23  Updated: 18/Dec/23  Resolved: 18/Dec/23

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 7.3.0-rc0

Type: Sub-task Priority: Major - P3
Reporter: Denis Grebennicov Assignee: Serhii Lysenko
Resolution: Fixed Votes: 0
Labels: M2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Sprint: QE 2023-07-24, QE 2023-08-21, QE 2023-09-04, QE 2023-09-18, QE 2023-10-02, QE 2023-10-16, QE 2023-10-30, QE 2023-11-13, QE 2023-11-27, QE 2023-12-11, QE 2023-12-25, QE 2024-01-08
Participants:

 Description   

Currently both setQuerySettings and setClusterParameter commands call setClusterParameter weak function, which contains the setClusterParameter implementation.

As part of this ticket, one would need to add a separate enum/bool flag to indicate whether the call is made internally (from setQuerySettings) or externally (directly setClusterParameters command call). Then through an uassert if it is an external call, yet querySettings cluster parameter is modified.

querySettings cluster parameter should only be modifiable through setQuerySettings and removeQuerySettings commands



 Comments   
Comment by Githook User [ 18/Dec/23 ]

Author:

{'name': 'Serhii Lysenko', 'email': 'serhii.lysenko@mongodb.com', 'username': 'serhiitea'}

Message: SERVER-78804 Prevent setClusterParameter being called on querySettings parameter

The fact that cluster-wide query settings are stored as one of cluster
parameters is an implementation detail. To set query settings, dedicated
setQuerySettings command should be used instead.

GitOrigin-RevId: 7deb90ce2db3f3c8f214fb268fb69ceadd3b6898
Branch: master
https://github.com/mongodb/mongo/commit/865ed52c56995117bcc6f102e65412ea07b035fa

Generated at Thu Feb 08 06:39:18 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.