Adds a new core_small_oplog_rs_kill_secondaries.yml suite that after
running tests for a certain period of time (defaults to 30 seconds),
resmoke.py will send a SIGKILL to all of the replica set's secondaries.
Each node is then restarted individually with the primary disabled to
verify it reaches the SECONDARY state within 5 minutes of starting up.
... and simplify ReplCoordTestFixture
ReplicationCoordinatorImpl consults the storage engine's isDurable flag for two purposes:
1. To choose whether to present the durable or applied optime when standing for
election in pv1
2. To decide how to interpret w:majority without an explicit j field when
waiting for write concern.
In the first case, it is unnecessary to choose which optime to apply based on
the isDurable flag. It is always safe and correct to present the applied optime,
because if the node presenting it wins election, it will attempt to commit that
applied optime. That means that voters may safely vote for that node.
In the second case, using the value of the local node's storage engine's
isDurable flag to adjust the meaning of w:majority is out of spec. Whether
w:majority writes wait for journaling is a function only of the
writeConcernMajorityJournalDefault flag when a write concern omits the "j"
field.
This patch removes the unnecessary consultation of the isDurable flag, and
uses the opportunity to simplify the constructor of
ReplicationCoordinatorImpl and its test fixture.
Makes it so that a link to the logs for every test that ran is present
in the sidebar of the Evergreen UI. Multiple entries will appear for
the same test file when --repeat is used.
This also fixes an issue where the number of tests skipped would be
incorrect if the same test file was included multiple times in the
"roots" key.
Change resmoke.py to wait up to 5 minutes for a mongod/mongos process
to start accepting connections. Waiting only 30 seconds for a
connection to be established is insufficient on some build variants in
Evergreen. This is likely due to file preallocation, disk speed, and
other resource factors.
Split out the passthrough tests into separate suites. The MongoDB
deployment is started up by resmoke.py so that we can record the
success/failure of each individual test in MCI.
Added support for parallel execution of tests by dispatching to
multiple MongoDB deployments.
Added support for grouping different kinds of tests (e.g. C++ unit
tests, dbtests, and jstests) so that they can be run together. This
allows for customizability in specifying what tests to execute when
changes are made to a particular part of the code.
