[SERVER-25976] Wait for replication of config.version write and config server index builds during ShardingTest setup Created: 06/Sep/16  Updated: 20/Sep/16  Resolved: 20/Sep/16

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

Type: Task Priority: Major - P3
Reporter: Spencer Brody (Inactive) Assignee: Andy Schwerin
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Duplicate
is duplicated by SERVER-26007 awaitReplication in ShardingTest afte... Closed
Related
related to SERVER-26042 Increase the timeout of ShardingTest ... Closed
is related to SERVER-14017 Refactor ShardingTest and ReplSetTest... Backlog
Sprint: Sharding 2016-09-19, Sharding 2016-10-10
Participants:
Linked BF Score: 0

 Description   

Some tests fail when trying to setChunkSize as the configRS nodes are still building indexes.



 Comments   
Comment by Spencer Brody (Inactive) [ 20/Sep/16 ]

There's no good way to do this that will work on all possible ShardingTest configurations. Test failure was worked around a different way (in SERVER-26042)

Comment by Spencer Jackson [ 09/Sep/16 ]

spencer If the shell running the test has been started with SSL, and is using the X509 client certificate, you should be able to run db.auth against the $external database. On master, you don't need to provide the username of the X509 user, so if you're using jstests/libs/client.pem you can run either:

MongoDB Enterprise > db.auth({user: "C=US,ST=New York,L=New York City,O=MongoDB,OU=KernelUser,CN=client", mechanism: "MONGODB-X509"})
1

for tests running on older versions of the shell/server, or

MongoDB Enterprise > db.auth({mechanism: "MONGODB-X509"})
1

You can also connect using server.pem to become the __system user.

Comment by Spencer Brody (Inactive) [ 08/Sep/16 ]

The alternative is if there's some way to authenticate connections within the shell with x509 (that doesn't involve launching a new shell process for every connection), then we could probably figure out in sharding test from the options we're given whether we're using keyfile or x509, and authenticate the connections to the config servers appropriately before calling awaitReplication(), though it may be tough to figure out from the options what the keyfile/x509 credentials are in every possible configuration. I also don't think there is such a way to authenticate connections in the shell with x509 - spencer.jackson, can you confirm?

Comment by Spencer Brody (Inactive) [ 08/Sep/16 ]

In lieu of a complete solution for SERVER-14017, the easiest and quickest way to work around this issue I can think of is to introduce a new method on ReplSetTest that basically does what awaitReplication/awaitLastOpCommitted do, but use isMaster (which doesn't require an authenticated connection to use) instead of replSetGetStatus.

Comment by Spencer Brody (Inactive) [ 08/Sep/16 ]

This is actually trickier than it seems like, because of the ssl and auth tests, there's no good way to call awaitReplication() on the config server ReplicaSetTest since awaitReplication uses replSetGetStatus which requires authentication, and there's no good generic way to authenticate the connections used that works in all configurations we run ShardingTests under.

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