[SERVER-57384] Remove serverStatus counters and logging for deleted opcodes Created: 03/Jun/21  Updated: 29/Oct/23  Resolved: 04/Aug/22

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 6.1.0-rc0

Type: Improvement Priority: Minor - P4
Reporter: David Storch Assignee: Irina Yatsenko (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by COMPASS-5998 Investigate changes in SERVER-57384: ... Closed
is depended on by TOOLS-3170 Investigate changes in SERVER-57384: ... Closed
Documented
is documented by DOCS-15524 [SERVER] Remove serverStatus counters... Closed
Related
is related to SERVER-55788 Deprecate legacy wire protocol opcodes Closed
is related to SERVER-56501 Add op counters for legacy op codes (... Closed
Backwards Compatibility: Fully Compatible
Sprint: QE 2022-07-11, QE 2022-07-25, QE 2022-08-08
Participants:

 Description   

We are planning to remove support for OP_INSERT, OP_UPDATE, OP_DELETE, OP_QUERY, OP_GET_MORE, OP_KILL_CURSORS, and getLastError in an upcoming version (likely 5.1). However, we are going to leave logic from SERVER-56501 to count attempted uses of the deleted opcodes. This will allow us to determine whether, and how often, applications are attempting to use the no-longer-supported op codes against a particular server. Similarly, the warning logging first introduced in SERVER-55788 will be initially left in place.

Eventually, once we are sure that users have taken all necessary action to avoid use of the legacy opcodes, we should delete the remaining traces of the legacy opcodes in the server code. Rather than producing a clean error message saying something like "OP_QUERY is no longer supported, please upgrade your driver", logging a warning to the same effect, and bumping a serverStatus() counter, after this change the server will instead produce an error with some obscure error message related to validation of the wire protocol message's structure (something like "unknown opcode 2004").

The version in which we should make this change is an open question. My initial proposal would be to schedule it for some version greater than 6.0, for example 6.1 or 6.2. That way, the initial deprecation will have happened in 5.0, there will still be useful error messages in 6.0, and post-6.0 all traces of the legacy opcodes will finally be fully removed.



 Comments   
Comment by Irina Yatsenko (Inactive) [ 04/Aug/22 ]

Has been committed to master with a64e8b26f54 on 2022-08-03.

Comment by Kyle Suarez [ 12/Jul/22 ]

Tagging joe.sack@mongodb.com and christopher.harris@mongodb.com on the above question while Katya is on vacation.

Comment by Irina Yatsenko (Inactive) [ 12/Jul/22 ]

david.storch@mongodb.com , kateryna.kamenieva@mongodb.com do we still want to log/count OP_QUERY when used for the allowed commands?

UPD: I've misread the code, we do not log OP_QUERY when it's used for the allowed commands.

Comment by Katya Kamenieva [ 13/Apr/22 ]

LGTM removing metrics starting 6.1

Comment by David Storch [ 08/Apr/22 ]

kateryna.kamenieva@mongodb.com do you think that we can do this immediately after branching for 6.0, or do we want to keep these counters around a little longer? Presumably since people always have to upgrade to 6.0, whether they are on LTS or rapid releases, these metrics will no longer be relevant as people try to upgrade beyond 6.0, meaning they are safe to remove in 6.1?

Comment by Kyle Suarez [ 07/Apr/22 ]

Removing it from "6.0 Required" and moving it to the 6.0 Upgrade/Downgrade project with the rest of the "do this after 6.0" tasks.

Comment by Ethan Zhang (Inactive) [ 09/Jun/21 ]

We mark it 6.0 just to remind ourselves.

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