[SERVER-21485] Capability to bind an existing cluster to ShardingTest Created: 16/Nov/15  Updated: 06/Dec/22  Resolved: 19/Nov/21

Status: Closed
Project: Core Server
Component/s: Sharding, Testing Infrastructure
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Jonathan Abrahams Assignee: Backlog - Server Tooling and Methods (STM) (Inactive)
Resolution: Done Votes: 0
Labels: stm
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-34289 Allow FSM test suites to connect to a... Closed
Assigned Teams:
Server Tooling & Methods
Sprint: TIG 2018-03-26
Participants:

 Description   

It would be very useful if an existing cluster could instantiate and bind to a ShardingTest object.



 Comments   
Comment by Kaloian Manassiev [ 13/Apr/18 ]

The sharding team won't have the resources to do this in the near future. Putting in in on the TIG backlog - we will accept CRs, otherwise we won't fix it.

Comment by Robert Guo (Inactive) [ 03/Apr/18 ]

The original approach used the config.mongos collection to get the list of connected mongos's, but as that collection is updated asynchronously, the shell does not know when it is up-to-date.

I'm moving this ticket over to the sharding team to consider adding a test-only command to trigger the "sharding uptime reporter" thread or to wait until the collection is synchronized.

For our testing that use resmoke clusters, we're going with an interim solution of recording the list of mongoses through TestData. See SERVER-34289 for more information.

Comment by Max Hirschhorn [ 07/Mar/18 ]

Kal did this for ReplSetTest already in e2e4c75 as part of his changes from SERVER-21050.

Generated at Thu Feb 08 03:57:29 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.