-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Conversation
❌ 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? |
❌ 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? |
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. |
Codecov ReportAttention: Patch coverage is
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. |
There was a problem hiding this 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); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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)) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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!
❌ 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? |
❌ 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? |
❕ 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. |
Known flaky org.opensearch.action.admin.cluster.node.tasks.ResourceAwareTasksTests.testTaskResourceTrackingDuringTaskCancellation #14293 |
@@ -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); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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)); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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)
❌ 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? |
This PR has screwed-up after multiple rebase, so created a new PR - #14723 |
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 has been documented.API changes companion pull request created.Failing checks are inspected and point to the corresponding known issue(s) (See: Troubleshooting Failing Builds)Commit changes are listed out in CHANGELOG.md file (See: Changelog)Public documentation issue/PR createdBy 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.