Skip to content

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

Closed
akolarkunnu wants to merge 0 commit intoopensearch-project:mainfrom
akolarkunnu:metadata
Closed

[Metadata Immutability] Change different indices lookup objects from array type to lists#14557
akolarkunnu wants to merge 0 commit intoopensearch-project:mainfrom
akolarkunnu:metadata

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 muneer.kolarkunnu@netapp.com

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.

@github-actions
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?

@github-actions
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 ?

@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.

@github-actions
Copy link
Contributor

✅ Gradle check result for 779e864: SUCCESS

@codecov
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?

* Returns all the concrete indices that are not hidden in the format of array of strings.
*/
public String[] getConcreteVisibleIndices() {
return visibleIndices.toArray(String[]::new);
Copy link
Member

@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
Member

@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
Member

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
- [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
Member

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
Member

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!

@github-actions
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?

@github-actions
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?

@github-actions
Copy link
Contributor

github-actions bot commented Jul 9, 2024

✅ Gradle check result for 098be2e: SUCCESS

@github-actions
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

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
Member

@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)

*/
public ClusterStateHealth(final ClusterState clusterState) {
this(clusterState, clusterState.metadata().getConcreteAllIndices());
this(clusterState, clusterState.metadata().getConcreteAllIndices().toArray(String[]::new));
Copy link
Member

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
@github-actions
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

Comments