[SERVER-47495] Ban force reconfig with "newlyAdded" fields Created: 13/Apr/20  Updated: 29/Oct/23  Resolved: 14/May/20

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: 4.7.0

Type: Task Priority: Major - P3
Reporter: Judah Schvimer Assignee: Judah Schvimer
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Documented
is documented by DOCS-13648 Investigate changes in SERVER-47495: ... Closed
Related
is related to SERVER-46347 Ensure that force reconfigs are not g... Closed
is related to SERVER-46348 Test behavior when a user provides a ... Closed
is related to SERVER-46350 Test that force reconfig removes a 'n... Closed
is related to SERVER-46352 Ensure the 'newlyAdded' field is alwa... Closed
is related to SERVER-47331 Rethink the transition from force rec... Closed
Backwards Compatibility: Fully Compatible
Sprint: Repl 2020-05-04, Repl 2020-05-18
Participants:

 Description   

This is the outcome of the discussion in SERVER-47331.



 Comments   
Comment by Githook User [ 14/May/20 ]

Author:

{'name': 'Judah Schvimer', 'email': 'judah@mongodb.com', 'username': 'judahschvimer'}

Message: SERVER-47495 Ban force reconfig with "newlyAdded" fields
Branch: master
https://github.com/mongodb/mongo/commit/a9ca06f02bcb43e20223bea1efd5b6ccfc720a82

Comment by Judah Schvimer [ 16/Apr/20 ]

Ops Manager and Cloud Manager will make use of newlyAdded because they do whatever the user requests, so if a user requests to add a new node, that node will be added with newlyAdded.

newlyAdded should never be required for any workflow. All it does is indicate the primary should initiate an automatic reconfig later on. If a user wants a node to begin with votes:0 and then get votes:1 after an initial sync completes, but wants to do so in a force reconfig, they could do that via one force reconfig to give it votes:0 and then a reconfig later (hopefully safe, but could be force) to give it votes:1. I would expect support to do this 2 reconfig approach rather than modify the config document on disk. I cannot think of a time that anyone would need to give a node newlyAdded.

louisa.berger, do you think this will cause any trouble for any Cloud products?
nuno.costa, do you think this will cause any trouble for Support?

Comment by Tess Avitabile (Inactive) [ 16/Apr/20 ]

I apologize for re-opening this discussion. I agree that this guarantees safety of the subsequent automatic reconfig. I have a concern that force reconfig should be able to accept an arbitrary config, so that support can do required maintenance. If support needs to change to a config that includes a newlyAdded field, is the workaround to restart all nodes in standalone mode and modify the config document?

Also, while the newlyAdded field is never expected to be used in Atlas, will it be used in clusters managed by Ops Manager or Cloud Manager? Do they need to be consulted on this change?

Comment by Judah Schvimer [ 13/Apr/20 ]

This should change the test written in SERVER-46348.

Generated at Thu Feb 08 05:14:20 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.