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

[Metadata Immutability] Change different indices lookup objects from array type to lists #14557

Closed
wants to merge 0 commits into from

Conversation

akolarkunnu
Copy link
Contributor

Description

Changed the arrays to immutable List instances, added new versions of the getters which returns List instances.

Related Issues

Resolves #8647

Signed-off-by: Abdul Muneer Kolarkunnu [email protected]

Check List

  • New functionality includes testing.
  • All tests pass
  • New functionality has been documented.
  • New functionality has javadoc added
  • API changes companion pull request created.
  • Failing checks are inspected and point to the corresponding known issue(s) (See: Troubleshooting Failing Builds)
  • Commits are signed per the DCO using --signoff
  • Commit changes are listed out in CHANGELOG.md file (See: Changelog)
  • Public documentation issue/PR created

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 34849c8: 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
Contributor

❌ Gradle check result for 5affe72: 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?

@akolarkunnu
Copy link
Contributor Author

Can anyone help me to rerun the test suites which are failed ?

CHANGELOG-3.0.md Outdated Show resolved Hide resolved
@andrross
Copy link
Member

Can anyone help me to rerun the test suites which are failed ?

@akolarkunnu Can you rebase this PR with the latest from main? The recent release incremented version numbers and as a result backward compatibility tests are now failing here.

Copy link
Contributor

✅ Gradle check result for 779e864: SUCCESS

Copy link

codecov bot commented Jun 27, 2024

Codecov Report

Attention: Patch coverage is 76.47059% with 4 lines in your changes missing coverage. Please review.

Project coverage is 71.71%. Comparing base (0684342) to head (5c0949b).
Report is 14 commits behind head on main.

Files Patch % Lines
.../cluster/metadata/IndexNameExpressionResolver.java 75.00% 1 Missing and 1 partial ⚠️
...n/cluster/health/TransportClusterHealthAction.java 0.00% 1 Missing ⚠️
...arch/index/recovery/RemoteStoreRestoreService.java 0.00% 1 Missing ⚠️
Additional details and impacted files
@@             Coverage Diff              @@
##               main   #14557      +/-   ##
============================================
+ Coverage     71.68%   71.71%   +0.03%     
- Complexity    62365    62388      +23     
============================================
  Files          5148     5148              
  Lines        293297   293279      -18     
  Branches      42384    42383       -1     
============================================
+ Hits         210239   210325      +86     
+ Misses        65717    65601     -116     
- Partials      17341    17353      +12     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Member

@andrross andrross left a comment

Choose a reason for hiding this comment

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

Looks good to me. @sandeshkr419 can you review this as well?

*/
public String[] getConcreteVisibleIndices() {
return visibleIndices.toArray(String[]::new);
Copy link
Contributor

@sandeshkr419 sandeshkr419 Jun 29, 2024

Choose a reason for hiding this comment

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

I don't think we have any usage left for the existing methods which are returning as arrays.

We probably just need a single method for each case which returns it as a list:

public List<String> getConcreteVisibleIndices() {
        return visibleIndices;
    }

This comment applies to all utilities in the scope of this PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I had asked this query in bug - #8647 (comment)

Reply form Andrew was "This class is exposed to all OpenSearch plugins." Based on this I introduced new APIs.

Copy link
Contributor

@sandeshkr419 sandeshkr419 Jun 30, 2024

Choose a reason for hiding this comment

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

Got it. Makes sense.

I'm wondering what should be the plan to mark the old APIs as deprecated so that we remove them entirely in a later release.

@andrross any suggestions? How about we have different set of changes for 3.0 vs 2.x - in 3.0 we change the API construct - breaking changes, in 2.x we just add extra APIs.

Copy link
Member

Choose a reason for hiding this comment

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

Yeah, it's fair game to put the @Deprecated annotation on these APIs and then remove them on the main branch for the 3.0 release.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Updated this PR for 3.0 release as suggested. Just changed the return type of existing APIs from String array to Collection types.

Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks @akolarkunnu Changes make sense for 3.0 now with a minor code comment. Rest of it LGTM!

Also, removed 'backport-2.x' label to avoid auto-backporting to 2.x - I assume we will do a separate set of manual changes altogether for 2.x

CHANGELOG.md Outdated
@@ -11,6 +11,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
- [Writable Warm] Add composite directory implementation and integrate it with FileCache ([12782](https://github.com/opensearch-project/OpenSearch/pull/12782))
- Fix race condition while parsing derived fields from search definition ([14445](https://github.com/opensearch-project/OpenSearch/pull/14445))
- Add allowlist setting for ingest-common processors ([#14439](https://github.com/opensearch-project/OpenSearch/issues/14439))
- Add new APIs in the Metadata to get different indices in the form of List ([#14557](https://github.com/opensearch-project/OpenSearch/pull/14557))
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we need to just modify the utilities and not add any new ones. So we can edit the CHANGELOG to be something like "Modify the utilities in the Metadata.....". What do you say?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Updated CHANGELOG-3.0.md file as suggested, since this change is only for 3.0 release and fro 2.x it will be different changes.

Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks @akolarkunnu Changes make sense for 3.0 now with a minor code comment. Rest of it LGTM!

Copy link
Contributor

github-actions bot commented Jul 9, 2024

❌ Gradle check result for 1cfda8d: 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
Contributor

github-actions bot commented Jul 9, 2024

❌ Gradle check result for 88cd3df: 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
Contributor

github-actions bot commented Jul 9, 2024

✅ Gradle check result for 098be2e: SUCCESS

Copy link
Contributor

github-actions bot commented Jul 9, 2024

❕ Gradle check result for 5c0949b: UNSTABLE

Please review all flaky tests that succeeded after retry and create an issue if one does not already exist to track the flaky failure.

@akolarkunnu
Copy link
Contributor Author

akolarkunnu commented Jul 9, 2024

Known flaky org.opensearch.action.admin.cluster.node.tasks.ResourceAwareTasksTests.testTaskResourceTrackingDuringTaskCancellation #14293
Known flaky org.opensearch.repositories.azure.AzureBlobContainerRetriesTests.testWriteBlobWithRetries #14318
Known flaky org.opensearch.index.remote.RemoteSegmentTransferTrackerTests.testComputeTimeLagOnUpdate #14325

@@ -493,7 +493,7 @@ private ClusterHealthResponse clusterHealth(
String[] concreteIndices;
if (request.level().equals(ClusterHealthRequest.Level.AWARENESS_ATTRIBUTES)) {
String awarenessAttribute = request.getAwarenessAttribute();
concreteIndices = clusterState.getMetadata().getConcreteAllIndices();
concreteIndices = clusterState.getMetadata().getConcreteAllIndices().toArray(String[]::new);
Copy link
Contributor

@sandeshkr419 sandeshkr419 Jul 10, 2024

Choose a reason for hiding this comment

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

Does it make sense to change concreteIndices to lists as well? Instead of doing a back and forth to arrays?

I mean atleast in OpenSearch packages, we can ensure that we consume these concreteIndices as lists directly at all places. I mean, it looks like concreteIndices is actually just used in the constructor so, it might make sense to use it as list itself.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Addressed it in new PR #14723 (This PR has screwed-up after multiple rebase)

@@ -73,7 +73,7 @@ public final class ClusterStateHealth implements Iterable<ClusterIndexHealth>, W
* @param clusterState The current cluster state. Must not be null.
*/
public ClusterStateHealth(final ClusterState clusterState) {
this(clusterState, clusterState.metadata().getConcreteAllIndices());
this(clusterState, clusterState.metadata().getConcreteAllIndices().toArray(String[]::new));
Copy link
Contributor

Choose a reason for hiding this comment

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

Same comment as above- Does it make sense to change concreteIndices to lists as well? Instead of doing a back and forth to arrays?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Addressed it in new PR #14723 (This PR has screwed-up after multiple rebase)

@sandeshkr419 sandeshkr419 added >breaking Identifies a breaking change. and removed backport 2.x Backport to 2.x branch labels Jul 10, 2024
Copy link
Contributor

❌ Gradle check result for 26886e0: 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?

@akolarkunnu
Copy link
Contributor Author

This PR has screwed-up after multiple rebase, so created a new PR - #14723

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>breaking Identifies a breaking change. Cluster Manager enhancement Enhancement or improvement to existing feature or request good first issue Good for newcomers
Projects
Status: ✅ Done
Development

Successfully merging this pull request may close these issues.

[Metadata Immutability] Change different indices lookup objects from array type to lists
3 participants