[DOCS-10939] Add change to {getParameter: 1, featureCompatibilityVersion: 1} for Server 3.6 Created: 24/Oct/17  Updated: 29/Oct/23  Resolved: 15/Nov/17

Status: Closed
Project: Documentation
Component/s: manual, Server
Affects Version/s: None
Fix Version/s: 3.6.0-rc2

Type: Task Priority: Major - P3
Reporter: Tess Avitabile (Inactive) Assignee: Kay Kim (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Documented
documents SERVER-31630 getParameter for featureCompatibility... Closed
Participants:
Days since reply: 6 years, 13 weeks ago
Epic Link: DOCS: 3.6 Server
Story Points: 0.2

 Description   

After SERVER-31630, the output of {getParameter: 1, featureCompatibilityVersion: 1} on a 3.6 mongod can have four possible returns:

Fully downgraded featureCompatibilityVersion:

{featureCompatibilityVersion: {version: "3.4"}, ok: 1}

Upgrading featureCompatibilityVersion:

{featureCompatibilityVersion: {version: "3.4", targetVersion: "3.6"}, ok: 1}

Downgrading featureCompatibilityVersion:

{featureCompatibilityVersion: {version: "3.4", targetVersion: "3.4"}, ok: 1}

Fully upgraded featureCompatibilityVersion:

{featureCompatibilityVersion: {version: "3.6"}, ok: 1}

We should document the change to the getParameter output. We should also include in the downgrade instructions to wait for each node to have fully downgraded featureCompatibilityVersion before replacing the binary.



 Comments   
Comment by Githook User [ 15/Nov/17 ]

Author:

{'name': 'kay', 'username': 'kay-kim', 'email': 'kay.kim@10gen.com'}

Message: DOCS-10939: fcv value
Branch: master
https://github.com/mongodb/docs/commit/ea9df136bb8ff1b287d72a8844a1cca4a4e1bfa1

Comment by Kay Kim (Inactive) [ 13/Nov/17 ]

Thanks much. Will try that.

Comment by Tess Avitabile (Inactive) [ 13/Nov/17 ]

It is hard to see the targetVersion in the getParameter output, since usually we proceed immediately into the fully upgraded or fully downgraded state.

One way you can be sure to see it is by doing a direct write to admin.system.version, as in this test. Of course, we don't want users to write directly to admin.system.version, but this will allow you to observe the targetVersion in the getParameter output.

How you might see it in the real world is when the config primary can't connect to one of the shards during upgrade or downgrade, so it cannot complete the upgrade or downgrade process. We simulate that in this test.

Generated at Thu Feb 08 08:01:43 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.