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

Add support for index pattern exclusion in CCR AutoFollow #72935

Merged
merged 11 commits into from
Jun 4, 2021

Conversation

fcofdez
Copy link
Contributor

@fcofdez fcofdez commented May 11, 2021

This pull request adds the ability to specify exclusion patterns for Auto-Follow patterns. This allows excluding indices that match any of the inclusion patterns and also match some of the exclusion patterns giving more fine grained control in scenarios where this is important.

Related #67686

@fcofdez fcofdez force-pushed the add-exclusion-pattern-auto-follow branch from af122b7 to 29119ef Compare May 11, 2021 14:37
@fcofdez fcofdez force-pushed the add-exclusion-pattern-auto-follow branch from 1c76a5b to 9ec9685 Compare May 11, 2021 16:42
@fcofdez fcofdez added Team:Distributed (Obsolete) Meta label for distributed team (obsolete). Replaced by Distributed Indexing/Coordination. :Distributed Indexing/CCR Issues around the Cross Cluster State Replication features v8.0.0 >enhancement v7.14.0 labels May 12, 2021
@fcofdez fcofdez requested a review from henningandersen May 12, 2021 08:21
@fcofdez fcofdez marked this pull request as ready for review May 12, 2021 08:21
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-distributed (Team:Distributed)

Copy link
Contributor

@henningandersen henningandersen left a comment

Choose a reason for hiding this comment

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

Thanks, this is looking good. I have a number of smaller comments only. I will request review from Tanguy too, since he authored auto-following initially.

@henningandersen henningandersen requested a review from tlrx May 14, 2021 08:48
Copy link
Member

@tlrx tlrx left a comment

Choose a reason for hiding this comment

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

I left some minor comments and I agree with Henning's comments that should be addressed. Looks good o.w. 👍

Comment on lines 225 to 227
assertBusy(() -> {
assertThat(getNumberOfSuccessfulFollowedIndices(), equalTo(initialNumberOfSuccessfulFollowedIndices + 1));
});
Copy link
Member

Choose a reason for hiding this comment

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

+1

I would also prefer to use a test specific prefix for the autofollow pattern name and inclusion/exclusion patterns (like testexcluions-*) because all tests share the same cluster which is not cleaned up after a test case is executed. Using a test specific prefix helps to debug those when they fail.

@fcofdez fcofdez requested review from tlrx and henningandersen May 25, 2021 11:23
@fcofdez
Copy link
Contributor Author

fcofdez commented May 25, 2021

Thanks both for the review, I've addressed your comments.

@@ -39,6 +39,7 @@
for (int i = 0; i < numPatterns; i++) {
String remoteCluster = randomAlphaOfLength(4);
List<String> leaderIndexPatterns = Collections.singletonList(randomAlphaOfLength(4));
List<String> leaderIndexExclusionsPatterns = Collections.singletonList(randomAlphaOfLength(4));
Copy link
Member

Choose a reason for hiding this comment

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

Maybe randomize with empty, single and multiple exclusions patterns?

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 in c531a60

@@ -84,6 +204,7 @@
body:
remote_cluster: local
leader_index_patterns: ['logs-*']
leader_index_exclusion_patterns: ['logs-excluded']
Copy link
Member

Choose a reason for hiding this comment

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

I would have expected bwc tests to fail with this 🤔

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's right, maybe for a PR we don't execute all the BWC test matrix? I'll remove the exclusion pattern in that test.

});
assertTrue(ESIntegTestCase.indexExists("copy-logs-201701", followerClient()));

createLeaderIndex("logs-201801", leaderIndexSettings);
Copy link
Member

Choose a reason for hiding this comment

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

@fcofdez I don't think it is resolved, doesn't it?

final IndexMetadata leaderIndexMetadata = remoteMetadata.index(leaderIndexName);

if (AutoFollowPattern.match(newLeaderPatterns, newLeaderIndexExclusionPatterns, indexAbstraction) == false) {
logger.warn("The follower index {} for leader index {} does not match against the updated auto follow " +
Copy link
Member

Choose a reason for hiding this comment

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

I'm a bit torn about this - I wonder if we should make it more explicit to the user by returning an error. The same question applies when inclusion patterns are updated - a follower index might previously match a pattern but not anymore. Maybe we should prevent such update and require either a new pattern to be created or the follower indices to be unfollowed first?

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 wasn't sure about what we wanted to do in these cases. I'm wondering if returning an error when a follower index was matching a previous pattern is a breaking change or not. In any case I think it's sensible to return an error in this scenario, I'll include it 👍.

Copy link
Member

Choose a reason for hiding this comment

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

In any case I think it's sensible to return an error in this scenario, I'll include it +1.

Maybe wait for @henningandersen's opinion first

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We discussed this offline and we agreed that instead of emitting a warning or failing the request when an Auto-Follow patter is updated and previously configured follower indices don't match anymore we'll keep the current behaviour. Instead we'll improve the current docs.

@fcofdez fcofdez requested a review from tlrx June 2, 2021 09:49
Copy link
Member

@tlrx tlrx left a comment

Choose a reason for hiding this comment

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

LGTM

---
"Test put and delete auto follow pattern with exclusion patterns":
- skip:
version: " - 7.13.99"
Copy link
Member

Choose a reason for hiding this comment

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

I'm surprised this test passed when executed against the 7.x branch 🤔

@fcofdez fcofdez merged commit a8101f3 into elastic:master Jun 4, 2021
@fcofdez
Copy link
Contributor Author

fcofdez commented Jun 4, 2021

Thanks Tanguy and Henning!

fcofdez added a commit to fcofdez/elasticsearch that referenced this pull request Jun 4, 2021
This commit adds the ability to specify exclusion patterns in Auto-Follow patterns.
This allows excluding indices that match any of the inclusion patterns and also match
some of the exclusion patterns giving more fine grained control in scenarios where this is important.

Related elastic#67686
Backport of elastic#72935
fcofdez added a commit that referenced this pull request Jun 4, 2021
This commit adds the ability to specify exclusion patterns in Auto-Follow patterns.
This allows excluding indices that match any of the inclusion patterns and also match
some of the exclusion patterns giving more fine grained control in scenarios where this is important.

Related #67686
Backport of #72935
fcofdez added a commit that referenced this pull request Jun 4, 2021
fcofdez added a commit to fcofdez/elasticsearch that referenced this pull request Jun 7, 2021
…llowed

Use an empty ClusterState as a base cluster state for that test

Closes elastic#73797
Relates elastic#72935
fcofdez added a commit that referenced this pull request Jun 7, 2021
…llowed (#73811)

Use an empty ClusterState as a base cluster state to take into account
the case where no leader candidate indices are created

Closes #73797
Relates #72935
fcofdez added a commit to fcofdez/elasticsearch that referenced this pull request Jun 7, 2021
…llowed

Use an empty ClusterState as a base cluster state to take into account
the case where no leader candidate indices are created

Closes elastic#73797
Relates elastic#72935
Backport of elastic#73811
fcofdez added a commit that referenced this pull request Jun 7, 2021
…llowed (#73826)

Use an empty ClusterState as a base cluster state to take into account
the case where no leader candidate indices are created

Closes #73797
Relates #72935
Backport of #73811
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Distributed Indexing/CCR Issues around the Cross Cluster State Replication features >enhancement Team:Distributed (Obsolete) Meta label for distributed team (obsolete). Replaced by Distributed Indexing/Coordination. v7.14.0 v8.0.0-alpha1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants