[SERVER-24792] Ensure that mongos from 3.4 will refuse to talk to mongod from 3.2 Created: 24/Jun/16  Updated: 19/Nov/16  Resolved: 20/Sep/16

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: 3.3.14

Type: Task Priority: Major - P3
Reporter: Spencer Brody (Inactive) Assignee: Nathan Myers
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File new_mongos_old_mongod.js    
Issue Links:
Depends
depends on SERVER-25393 Wire Protocol Version checking not do... Closed
Related
related to SERVER-25514 prevent 3.4 config from adding a 3.2 ... Closed
Backwards Compatibility: Fully Compatible
Sprint: Sharding 18 (08/05/16), Sharding 2016-08-29, Sharding 2016-09-19, Sharding 2016-10-10
Participants:
Linked BF Score: 0

 Comments   
Comment by Githook User [ 20/Sep/16 ]

Author:

{u'name': u'Nathan Myers', u'email': u'ncm@asperasoft.com'}

Message: SERVER-24792 verify new mongos -> old mongod fails
Branch: master
https://github.com/mongodb/mongo/commit/1d5eff62fc2ab422c9efe5d3ad7b6f82345b127b

Comment by Githook User [ 20/Sep/16 ]

Author:

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

Message: Revert "SERVER-24792 verify new mongos -> old mongod fails"

This reverts commit dc405959d785dc1f50682877d732da0124e4b3b2.
Branch: master
https://github.com/mongodb/mongo/commit/3117e5134a78ec59a3fbd30dfc5b82b850b6ce0c

Comment by Githook User [ 20/Sep/16 ]

Author:

{u'name': u'Nathan Myers', u'email': u'ncm@asperasoft.com'}

Message: SERVER-24792 verify new mongos -> old mongod fails
Branch: master
https://github.com/mongodb/mongo/commit/dc405959d785dc1f50682877d732da0124e4b3b2

Comment by Nathan Myers [ 15/Sep/16 ]

Changes are at https://github.com/nathan-myers-mongo/mongo/tree/server-24792-no-connect-old

Comment by Esha Maharishi (Inactive) [ 08/Sep/16 ]

Additional note: write operations (insert, update, remove) will show the failure as part of writeErrors, not as part of the top-level command error.

nathan.myers, you might want to user assert.writeError() for the write operations instead of assert.commandFailed() (the attached script currently uses assert.commandFailed() incorrectly).

Comment by Esha Maharishi (Inactive) [ 08/Sep/16 ]

At a minimum, the following commands should be tested:

  • insert
  • update
  • remove
  • find
  • count
  • aggregate

schwerin, I agree it would make sense to put this in jstests/multiVersion.

Comment by Andy Schwerin [ 24/Jun/16 ]

Is there an existing multiversion test, or should we add one, as well?

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