[SERVER-30624] Add featureCompatibilityVersion to serverStatus output Created: 11/Aug/17 Updated: 06/Dec/22 Resolved: 05/Sep/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Security |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Shane Harvey | Assignee: | Backlog - Query Team (Inactive) |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Assigned Teams: |
Query
|
||||||||||||
| Participants: | |||||||||||||
| Description |
|
The only built in roles with the getParameter privilege are clusterMonitor, backup, restore, and root: https://docs.mongodb.com/manual/reference/built-in-roles/ However, an application can check the featureCompatibilityVersion indirectly. For example, issuing a find with a collation will return error code 72 "InvalidOptions" if the FCV is 3.2 on MongoDB 3.4. A similar work around for MongoDB 3.6 is left as an exercise to the reader. The featureCompatibilityVersion should be added to the serverStatus output, so that it can be read along with the binary version. |
| Comments |
| Comment by Ian Whalen (Inactive) [ 05/Sep/17 ] |
|
shane.harvey please reopen if you have more information about why this is needed. |
| Comment by Asya Kamsky [ 18/Aug/17 ] |
|
I was thinking it would make more sense to add it to db.version() but that just comes from db.serverBuildInfo().version It does seem like the sort of thing you'd want to know when checking the version though... |
| Comment by Tess Avitabile (Inactive) [ 14/Aug/17 ] |
|
The Sharding team does not require featureCompatibilityVersion to be added to the isMaster response, so I think a good feature request would be to add featureCompatibilityVersion to the serverStatus output. I've updated the ticket to reflect this. |
| Comment by Tess Avitabile (Inactive) [ 14/Aug/17 ] |
|
I am checking on |