[SERVER-80348] (SA) Spike/Investigate Having a Single ServiceContext manage multiple shard roles Created: 23/Aug/23  Updated: 26/Sep/23  Resolved: 08/Sep/23

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

Type: Task Priority: Major - P3
Reporter: George Wangensteen Assignee: George Wangensteen
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Sprint: Service Arch 2023-09-04, Service Arch 2023-09-18
Participants:

 Description   

Part of our current potential design-plan to enable shards to act as routers involves registering dual implementations of modules that currently might be implemented separately on mongod and mongos with a single service context in a single process, and teaching the system to use the right modules given the 'shard role context' of the calling code. Some examples of these modules include commands, MongoProcessInterfaces used by query, ServiceEntryPoints used to dispatch commands, etc. User and system operations should be 'tagged' with the role they are utilizing the process as (i.e. router or shard), and that 'tag' should be used to dispatch to the module that tag corresponds to.

We need to get a concrete estimation into what exactly will be involved in this work to produce an accurate timeline. In this ticket, we'll complete a spike of the work described above, in an attempt to run some subset of sharding-oriented tests against a mongod with an embedded router. We'll track what work was necessary to achieve this POC, what obstacles we identified to product-ionizing this work, and produce a time estimate of how long we'd expect this work to take.


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