[SERVER-69060] Associate server parameters with feature flags Created: 22/Aug/22  Updated: 29/Oct/23  Resolved: 27/Sep/22

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: 6.1 Desired
Fix Version/s: 6.2.0-rc0

Type: Task Priority: Major - P3
Reporter: Varun Ravichandran Assignee: Sara Golemon
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-69871 Move feature_flag into server_core Closed
Backwards Compatibility: Minor Change
Sprint: Security 2022-09-19, Security 2022-10-03
Participants:

 Description   

SERVER-65948 and SERVER-68202 introduced the changeStreams cluster parameter, which will be used to set the retention policy of change streams in serverless clusters. Although the parameter has now been introduced, the underlying work to make use of the parameter properly is only targeted for 6.2. As a result, the project is guarded behind a feature flag that will remain disabled for the 6.1 release. However, this feature flag is not being checked in getClusterParameter or setClusterParameter, meaning that external users will be able to set and see the value of changeStreams.expireAfterSeconds before it has any meaningful significance. This problem is likely to resurface in the future as additional cluster parameters are added to the server that control feature-flagged behavior.

The long-term solution is to bake feature flags into the IDL definitions of server parameters so that they can be arbitrarily included/excluded from setParameter/setClusterParameter/getParameter/getClusterParameter based on whether the specified feature flag is enabled or not.



 Comments   
Comment by Githook User [ 27/Sep/22 ]

Author:

{'name': 'Sara Golemon', 'email': 'sara.golemon@mongodb.com', 'username': 'sgolemon'}

Message: SERVER-69060 Guard server parameters on feature flags
Branch: master
https://github.com/mongodb/mongo/commit/2cfc78ff27a7ed95e7632f7749f8d09383be308b

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