[SERVER-35171] Update new_mongos_old_mongod_wire_version_clash.js Created: 22/May/18  Updated: 31/Jul/18  Resolved: 31/Jul/18

Status: Closed
Project: Core Server
Component/s: Testing Infrastructure, Upgrade/Downgrade
Affects Version/s: 4.0.0-rc0
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Robert Guo (Inactive) Assignee: Blake Oler
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-35169 Bump wire protocol version for 4.2 Closed
Sprint: Sharding 2018-07-02, Sharding 2018-07-16, Sharding 2018-07-30, Sharding 2018-08-13
Participants:

 Description   

The new_mongos_old_mongod_wire_version_clash.js test expects the last-stable version of mongo servers to issue an older wire version. But since we upgrade the wire protocol version independently of the server version, this assumption isn't always true.

The test should be modified to backtrack binary versions until it finds one that uses an older wire protocol version.

The test should also be unblacklisted as part of this ticket or SERVER-35169, whichever one happens first.



 Comments   
Comment by Blake Oler [ 31/Jul/18 ]

cheahuychou.mao attempted the ticket, and we both experienced issues getting older binary versions of mongos to start and connect to a last-stable binary cluster. There's probably an easy solution found with less than a day's worth of investigation. We just haven't had time to investigate the issue. The test is currently working as-is. Closing as Won't Fix.

Comment by Robert Guo (Inactive) [ 19/Jul/18 ]

blake.oler That is an interesting idea. But I'm slightly concerned that it doesn't work well with the server team's current development workflow, where tests that pass are never looked at. As such, someone would have to remember to look at that test before the release (and after bumping the wire protocol version) to ensure it is doing the right thing. I fear that it's much easier to forget to do this than to have the test fail loudly after we branch, where it will definitely be noticed. The failure will only happen once a major release, so it's not particularly critical that we fix it now.

Would you mind writing a sentence or two on what has been attempted and why it didn't work? (I had thought there was a CR that went by). Feel free to close the ticket as "Won't Fix" afterwards. We can figure out a different approach for the next release

Comment by Blake Oler [ 19/Jul/18 ]

robert.guo any thoughts on the aforementioned?

Comment by Cheahuychou Mao [ 12/Jul/18 ]

greg.mckeon It's not. I'll remove the comment above. Sorry about that. 

Comment by Gregory McKeon (Inactive) [ 12/Jul/18 ]

blake.oler cheahuychou.mao is this in code review?

Comment by Blake Oler [ 10/Jul/18 ]

I'm not sure if the above behavior is actually true. Tested this out with some other team members. However, after some thinking – eventually, for every release, we will update the wire version. It would be an easier solution to let the test pass when the wire versions are the same, but explicitly log to the users in the test that we are only passing due to an ongoing server upgrade project. I've completed a test patch as such and it works perfectly!

Comment by Robert Guo (Inactive) [ 05/Jul/18 ]

New behavior in 4.2 causes a mongos to automatically crash upon trying to connect to an older binary.

blake.oler I found crash_mongos_against_upgraded_cluster.js, which tests the behavior of an old mongos in a new cluster. Is there a different test for a new mongos in an old cluster?

Comment by Blake Oler [ 05/Jul/18 ]

robert.guo New behavior in 4.2 causes a mongos to automatically crash upon trying to connect to an older binary. That behavior is expressed in other tests... maybe this test is no longer relevant on master?

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