[TEST] Randomized number of shards used for indices created during tests #5356
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| assertThat(countResponse.getTotalShards(), equalTo(5)); | ||
| assertThat(countResponse.getSuccessfulShards(), equalTo(5)); | ||
| assertThat(countResponse.getTotalShards(), equalTo(numShards.numPrimaries)); | ||
| assertThat(countResponse.getSuccessfulShards(), equalTo(numShards.numPrimaries)); | ||
| assertThat(countResponse.getFailedShards(), equalTo(0)); |
There was a problem hiding this comment.
maybe have an assertTotalShards() and assertSuccessfulShards() or allows assertAllSuccessful() to provide an amount of shards as well
|
This change looks awesome. I think we should try to get it in very soon so that we don't get merge conflicts or need to track new tests that would be added in the mean time. |
| @@ -1031,4 +1063,23 @@ public static String randomBytesFieldDataFormat() { | |||
| return randomFrom(Arrays.asList("paged_bytes", "fst", "doc_values")); | |||
| } | |||
|
|
|||
| protected NumShards getNumShards(String index) { | |||
| MetaData metaData = client().admin().cluster().prepareState().get().getState().metaData(); | |||
| assert metaData.hasIndex(index); | |||
There was a problem hiding this comment.
use assertThat here please it will work even if asserts are disabled
|
@javanna I left one small comment! this looks awesome - please go ahead and push it asap! |
Introduced two levels of randomization for the number of shards (between 1 and 10) when running tests: 1) through the existing random index template, which now sets a random number of shards that is shared across all the indices created in the same test method unless overwritten 2) through `createIndex` and `prepareCreate` methods, similar to what happens using the `indexSettings` method, which changes for every `createIndex` or `prepareCreate` unless overwritten (overwrites index template for what concerns the number of shards) Added the following facilities to deal with the random number of shards: - `getNumShards` to retrieve the number of shards of a given existing index, useful when doing comparisons based on the number of shards and we can avoid specifying a static number. The method returns an object containing the number of primaries, number of replicas and the total number of shards for the existing index - added `assertFailures` that checks that a shard failure happened during a search request, either partial failure or total (all shards failed). Checks also the error code and the error message related to the failure. This is needed as without knowing the number of shards upfront, when simulating errors we can run into either partial (search returns partial results and failures) or total failures (search returns an error) - added common methods similar to `indexSettings`, to be used in combination with `createIndex` and `prepareCreate` method and explicitly control the second level of randomization: `numberOfShards`, `minimumNumberOfShards` and `maximumNumberOfShards`. Added also `numberOfReplicas` despite the number of replicas is not randomized (default not specified but can be overwritten by tests) Tests that specified the number of shards have been reviewed and the results follow: - removed number_of_shards in node settings, ignored anyway as it would be overwritten by both mechanisms above - remove specific number of shards when not needed - removed manual shards randomization where present, replaced with ordinary one that's now available - adapted tests that didn't need a specific number of shards to the new random behaviour - fixed a couple of test bugs (e.g. 3 levels parent child test could only work on a single shard as the routing key used for grand-children wasn't correct) - also done some cleanup, shared code through shard size facets and aggs tests and used common methods like `assertAcked`, `ensureGreen`, `refresh`, `flush` and `refreshAndFlush` where possible - made sure that `indexSettings()` is always used as a basis when using `prepareCreate` to inject specific settings - converted indexRandom(false, ...) + refresh to indexRandom(true, ...)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Introduced two levels of randomization for the number of shards (between 1 and 10) when running tests:
through the existing random index template, which now sets a random number of shards that is shared across all the indices created in the same test method unless overwritten
through
createIndexandprepareCreatemethods, similar to what happens using theindexSettingsmethod, which changes for everycreateIndexorprepareCreateunless overwritten (overwrites index template for what concerns the number of shards)Added the following facilities to deal with the random number of shards:
getNumShardsto retrieve the number of shards of a given existing index, useful when doing comparisons based on the number of shards and we can avoid specifying a static number. The method returns an object containing the number of primaries, number of replicas and the expected total number of shards for the existing indexassertFailuresthat checks that a shard failure happened during a search request, either partial failure or total (all shards failed). Checks also the error code and the error message related to the failure. This is needed as without knowing the number of shards upfront, when simulating errors we can run into either partial (search returns partial results and failures) or total failures (search returns an error)indexSettings, to be used in combination withcreateIndexandprepareCreatemethod and explicitly control the second level of randomization:numberOfShards,minimumNumberOfShardsandmaximumNumberOfShards. Added alsonumberOfReplicasdespite the number of replicas is not randomized (default not specified but can be overwritten by tests)Tests that specified the number of shards have been reviewed:
assertAcked,ensureGreen,refresh,flushandrefreshAndFlushwhere possible