[SERVER-78810] Improve Cluster Role API usability Created: 10/Jul/23  Updated: 02/Feb/24

Status: Open
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Minor - P4
Reporter: Antonio Fuschetto Assignee: Backlog - Catalog and Routing
Resolution: Unresolved Votes: 0
Labels: oldshardingemea, pm-635-milestone-3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-85770 Enable internal routing capabilities ... Open
related to SERVER-85974 Complete TODO listed in SERVER-78810 Backlog
related to SERVER-79545 Improve ClusterRole class Backlog
Assigned Teams:
Catalog and Routing
Participants:

 Description   

The current ClusterRole API exposes a set of very open and generic functions that don't auto-describe the real use causes that the callers want to achieve.

In order to improve the readability of the code, the idea is to expose an API with clear function names that better descrive what they do.

The instances of this class model the role (or roles) of the current process (node) that is actually a member of a sharded cluster. If the process is a standalone or a replica set member, then there is no cluster role.

An draft idea is to have an API that looks as follows:

  • isRouterOnly
  • isRouter
  • isShardOnly
  • isShard


 Comments   
Comment by Antonio Fuschetto [ 02/Feb/24 ]

After an internal discussion, we spotted situations where it makes sense to have a more explicative API, e.g., to quicky identify if the process is a MongoS or MondD, a shard or a config server (only), etc.

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