[Metadata Immutability] Change different indices lookup objects from array type to lists#14557
[Metadata Immutability] Change different indices lookup objects from array type to lists#14557akolarkunnu wants to merge 0 commit intoopensearch-project:mainfrom
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. |
andrross
left a comment
There was a problem hiding this comment.
Looks good to me. @sandeshkr419 can you review this as well?
| * Returns all the concrete indices that are not hidden in the format of array of strings. | ||
| */ | ||
| public String[] getConcreteVisibleIndices() { | ||
| return visibleIndices.toArray(String[]::new); |
There was a problem hiding this comment.
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.
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.
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.
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.
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.
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
| - [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.
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.
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.
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 |
| 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.
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.
Addressed it in new PR #14723 (This PR has screwed-up after multiple rebase)
| */ | ||
| 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.
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.
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 muneer.kolarkunnu@netapp.com
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.