Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changes ConcurrentSearchTasksIT to use custom slice count #17355

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

rampreeth
Copy link
Contributor

Description

Changes ConcurrentSearchTasksIT to use custom slice count

Related Issues

Resolves #9317

Check List

  • Functionality includes testing.
  • API changes companion pull request created, if applicable.
  • Public documentation issue/PR created, if applicable.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Copy link
Contributor

❌ Gradle check result for 8ea75ef: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

Signed-off-by: Rampreeth Ethiraj <ethirajrampreeth@gmail.com>
Copy link
Contributor

❌ Gradle check result for 9abade8: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

Signed-off-by: Rampreeth Ethiraj <ethirajrampreeth@gmail.com>
Copy link
Contributor

❌ Gradle check result for c4d000a: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

Signed-off-by: Rampreeth Ethiraj <ethirajrampreeth@gmail.com>
Copy link
Contributor

❌ Gradle check result for fa04c65: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

Copy link
Collaborator

@jed326 jed326 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for working on this @rampreeth!

@@ -248,6 +248,7 @@ static Setting<Integer> buildNumberOfShardsSetting() {
static final String MAX_NUMBER_OF_SHARDS = "opensearch.index.max_number_of_shards";
public static final Setting<Integer> INDEX_NUMBER_OF_SHARDS_SETTING = buildNumberOfShardsSetting();
public static final String SETTING_NUMBER_OF_REPLICAS = "index.number_of_replicas";
public static final String MAX_SLICE_COUNT = "index.search.concurrent.max_slice_count";
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we either also use this same string in the setting name:

public static final Setting<Integer> INDEX_CONCURRENT_SEGMENT_SEARCH_MAX_SLICE_COUNT = Setting.intSetting(
"index.search.concurrent.max_slice_count",
CONCURRENT_SEGMENT_SEARCH_TARGET_MAX_SLICE_COUNT_DEFAULT_VALUE,
CONCURRENT_SEGMENT_SEARCH_TARGET_MAX_SLICE_COUNT_DEFAULT_VALUE,
Property.Dynamic,
Property.IndexScope
);

or, we can just do:

INDEX_CONCURRENT_SEGMENT_SEARCH_MAX_SLICE_COUNT.getKey()

That way if we ever need to change the setting there's only 1 place to modify instead of 2.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this comment needs to be addressed still too

@@ -89,6 +90,7 @@ public void testConcurrentSearchTaskTracking() {
Settings.builder()
.put(IndexMetadata.SETTING_NUMBER_OF_SHARDS, NUM_SHARDS)
.put(IndexMetadata.SETTING_NUMBER_OF_REPLICAS, 0)
.put(IndexMetadata.MAX_SLICE_COUNT, 5)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One main goal of using the setting name is so we can use a random number here instead of hard coding to 5

Copy link
Contributor Author

@rampreeth rampreeth Feb 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jed326 , from what I understood, we need to assert the segment count by validating against the slice count that i sset. So, this particular line is where we're setting the slice count. Even if we were to use a random number, that particular value would still be hardcoded right? Please correct me if I'm missing something here

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

More specifically we're asserting that the stats are being tracked for all the slices. So the idea is if slice count is set to 2 then we check that the stats are tracked for 2 slices + search thread, etc. So setting the slice count to a random number between (1, num_segments) ensures we have full coverage and not some magical dependency on specifically 5 for example.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it, thanks for the clarification, will make the necessary changes

Signed-off-by: Rampreeth Ethiraj <ethirajrampreeth@gmail.com>
Copy link
Contributor

❌ Gradle check result for a519924: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

Copy link
Collaborator

@jed326 jed326 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @rampreeth , it looks like the spotless checks are failing too: https://build.ci.opensearch.org/job/gradle-check/53580/

  Run './gradlew :server:spotlessApply' to fix these violations.


Metadata metadata = client().admin().cluster().prepareState().get().getState().metadata();
assertEquals(
Integer.parseInt(metadata.index(INDEX_NAME).getSettings().get(IndexMetadata.MAX_SLICE_COUNT)),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should be the min of the slice count setting and the number of segments. Otherwise this test might be a little flaky depending on the refresh interval of the index and the maxSliceCount (for example, if maxSliceCount == 7 but somehow only 5 segments were created, then this should be only 5 still).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Enhancement or improvement to existing feature or request good first issue Good for newcomers skip-changelog :test Adding or fixing a test
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Concurrent Segment Search] Change ConcurrentSearchTasksIT to use custom slice count
2 participants