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

Make searchable snapshot indexes read-only but allow deletion #4764

Merged

Conversation

Vishalks
Copy link
Contributor

@Vishalks Vishalks commented Oct 13, 2022

Signed-off-by: Vishal Sarda vsarda@amazon.com

Co-author: @andrross

Description

The changes in this PR are made on top of #4680. This PR makes the index restored from remote snapshot as read only, but it can be deleted. The write blocks on this index continue to be applicable even when explicitly set to false by user using "index.blocks.read_only_allow_delete": false. For any operations other than read on such an index, we throw an unsupported exception.

Issues Resolved

#4655

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.

Signed-off-by: Vishal Sarda <vsarda@amazon.com>
@github-actions
Copy link
Contributor

Gradle Check (Jenkins) Run Completed with:

@Vishalks Vishalks changed the title Make the index restored by remote snapshot as read only but deletable Make the index restored by remote snapshot as read only but allow deletion Oct 13, 2022
Signed-off-by: Vishal Sarda <vsarda@amazon.com>
Signed-off-by: Vishal Sarda <vsarda@amazon.com>
@Vishalks Vishalks marked this pull request as ready for review October 13, 2022 17:36
@Vishalks Vishalks requested review from a team and reta as code owners October 13, 2022 17:36
@github-actions
Copy link
Contributor

Gradle Check (Jenkins) Run Completed with:

@github-actions
Copy link
Contributor

Gradle Check (Jenkins) Run Completed with:

@@ -1227,6 +1227,7 @@ private static IndexMetadata addSnapshotToIndexSettings(IndexMetadata metadata,
.put(IndexSettings.SEARCHABLE_SNAPSHOT_ID_UUID.getKey(), snapshot.getSnapshotId().getUUID())
.put(IndexSettings.SEARCHABLE_SNAPSHOT_ID_NAME.getKey(), snapshot.getSnapshotId().getName())
.put(IndexSettings.SEARCHABLE_SNAPSHOT_INDEX_ID.getKey(), indexId.getId())
.put(IndexMetadata.APIBlock.READ_ONLY_ALLOW_DELETE.settingName(), true)
Copy link
Collaborator

Choose a reason for hiding this comment

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

With DiskThresholdDecider be able to revert this?

…read only block by disk threshold monitor

Signed-off-by: Vishal Sarda <vsarda@amazon.com>
@@ -356,6 +357,7 @@ public void onNewInfo(ClusterInfo info) {
final Set<String> indicesToAutoRelease = StreamSupport.stream(state.routingTable().indicesRouting().spliterator(), false)
.map(c -> c.key)
.filter(index -> indicesNotToAutoRelease.contains(index) == false)
.filter(index -> !state.getMetadata().settings().get(IndexModule.INDEX_STORE_TYPE_SETTING.getKey()).equals(IndexModule.Type.REMOTE_SNAPSHOT.getSettingsKey()))
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@Bukhtawar I have added this so that disk threshold monitor filters out index backed by remote snapshot from list of indices to be released, but currently I can't find a way to test it locally (discussed more details on slack). Can you suggest a way to test this in run time (somehow the monitor selects some indices to auto release but not the remote ones)?

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 explore using a separate block so that concerns are separate and we don't run into each other?

@github-actions
Copy link
Contributor

Gradle Check (Jenkins) Run Completed with:

@andrross
Copy link
Member

Looks like a test failure related to this change: https://build.ci.opensearch.org/job/gradle-check/4913/testReport/junit/org.opensearch.index.reindex/DeleteByQueryBasicTests/testDeleteByQueryOnReadOnlyAllowDeleteIndex/

Looking at the log I found this:

java.lang.NullPointerException: Cannot invoke "String.equals(Object)" because the return value of "org.opensearch.common.settings.Settings.get(String)" is null
	at org.opensearch.cluster.routing.allocation.DiskThresholdMonitor.lambda$onNewInfo$4(DiskThresholdMonitor.java:360) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]

Signed-off-by: Vishal Sarda <vsarda@amazon.com>
Signed-off-by: Vishal Sarda <vsarda@amazon.com>
@github-actions
Copy link
Contributor

Gradle Check (Jenkins) Run Completed with:

@github-actions
Copy link
Contributor

Gradle Check (Jenkins) Run Completed with:

@andrross
Copy link
Member

Can you add some tests? Maybe some additional tests to SearchableSnapshotIT

@github-actions
Copy link
Contributor

Gradle Check (Jenkins) Run Completed with:

@github-actions
Copy link
Contributor

Gradle Check (Jenkins) Run Completed with:

@andrross
Copy link
Member

The problem with this approach is that the following operation works and will undo this setting:

PUT my_index/_settings
{
    "index": {
        "blocks.write": false
    }
}

I think some setting changes make sense for searchable snapshots and others don't. A reasonable approach is probably to block all setting changes initially for searchable snapshots and then work through the design and implementation of allowing particular operations where appropriate. That is the ultimate goal of issue #4655.

Signed-off-by: Vishal Sarda <vsarda@amazon.com>
@Vishalks
Copy link
Contributor Author

The problem with this approach is that the following operation works and will undo this setting:

PUT my_index/_settings
{
    "index": {
        "blocks.write": false
    }
}

I think some setting changes make sense for searchable snapshots and others don't. A reasonable approach is probably to block all setting changes initially for searchable snapshots and then work through the design and implementation of allowing particular operations where appropriate. That is the ultimate goal of issue #4655.

Isn't that API allowed to be only called by the admin? If yes, letting admin tweak the index settings seems reasonable to me.

@github-actions
Copy link
Contributor

Gradle Check (Jenkins) Run Completed with:

@andrross
Copy link
Member

Isn't that API allowed to be only called by the admin? If yes, letting admin tweak the index settings seems reasonable to me.

A searchable snapshot index cannot be writable, so it's wrong to let the API block be removed, admin or not. There's a whole host of settings that don't apply to an inherently read-only index.

Signed-off-by: Vishal Sarda <vsarda@amazon.com>
@Vishalks
Copy link
Contributor Author

Isn't that API allowed to be only called by the admin? If yes, letting admin tweak the index settings seems reasonable to me.

A searchable snapshot index cannot be writable, so it's wrong to let the API block be removed, admin or not. There's a whole host of settings that don't apply to an inherently read-only index.

I assumed that since #4655 mentions 'user should not be able to change index settings', letting them affected through admin should be fine (admin > user). Seems like it's not the case.

@github-actions
Copy link
Contributor

Gradle Check (Jenkins) Run Completed with:

@stephen-crawford
Copy link
Contributor

Hi @Vishalks, I am reaching out from the security team to check in and see if there was anything you may need from our end. I have been going to through active issues tagged for the upcoming release and trying to check in with any that look like they may brush with us. Let me know if you need anything from us.

@andrross
Copy link
Member

Hey @scrawfor99 thanks for checking in. This task is about configuring static API blocks for the experimental searchable snapshot indexes. There shouldn't need to be any changes from the security team.

Signed-off-by: Vishal Sarda <vsarda@amazon.com>
Signed-off-by: Vishal Sarda <vsarda@amazon.com>
@github-actions
Copy link
Contributor

Gradle Check (Jenkins) Run Completed with:

@github-actions
Copy link
Contributor

Gradle Check (Jenkins) Run Completed with:

@github-actions
Copy link
Contributor

Gradle Check (Jenkins) Run Completed with:

@kotwanikunal
Copy link
Member

rg.opensearch.qa.verify_version_constants.VerifyVersionConstantsIT > testLuceneVersionConstant FAILED
    java.lang.AssertionError: 
    Expected: <9.4.1>
         but: was <9.4.0>
        at __randomizedtesting.SeedInfo.seed([4E6DBD0DFC297DE6:C3088051DB21BEAF]:0)
        at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:18)
        at org.junit.Assert.assertThat(Assert.java:964)
        at org.junit.Assert.assertThat(Assert.java:930)
        at org.opensearch.qa.verify_version_constants.VerifyVersionConstantsIT.testLuceneVersionConstant(VerifyVersionConstantsIT.java:56)

@Vishalks can you please rebase the commit?

@github-actions
Copy link
Contributor

Gradle Check (Jenkins) Run Completed with:

@andrross andrross changed the title Make the index restored by remote snapshot as read only but allow deletion Make searchable snapshot indexes read-only but allow deletion Oct 27, 2022
@andrross andrross merged commit c4fc1bc into opensearch-project:main Oct 27, 2022
@andrross andrross added backport 2.x Backport to 2.x branch v2.4.0 'Issues and PRs related to version v2.4.0' labels Oct 27, 2022
@opensearch-trigger-bot
Copy link
Contributor

The backport to 2.x failed:

The process '/usr/bin/git' failed with exit code 1

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-2.x 2.x
# Navigate to the new working tree
cd .worktrees/backport-2.x
# Create a new branch
git switch --create backport/backport-4764-to-2.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 c4fc1bc0f29bc7a005e4755be5d2e1b22b7de72a
# Push it to GitHub
git push --set-upstream origin backport/backport-4764-to-2.x
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-2.x

Then, create a pull request where the base branch is 2.x and the compare/head branch is backport/backport-4764-to-2.x.

Vishalks added a commit to Vishalks/OpenSearch that referenced this pull request Oct 27, 2022
…arch-project#4764)

This commit adds a new cluster block that is added by default to all searchable
snapshot indexes to block writes and metadata changes.

Signed-off-by: Vishal Sarda <vsarda@amazon.com>
(cherry picked from commit c4fc1bc)
Signed-off-by: Vishal Sarda <vsarda@amazon.com>
andrross pushed a commit that referenced this pull request Oct 27, 2022
…#4958)

This commit adds a new cluster block that is added by default to all searchable
snapshot indexes to block writes and metadata changes.

(cherry picked from commit c4fc1bc)

Signed-off-by: Vishal Sarda <vsarda@amazon.com>
Co-authored-by: Vishal Sarda <Vishalks@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport 2.x Backport to 2.x branch v2.4.0 'Issues and PRs related to version v2.4.0'
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants