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

[7.x] Deprecate Auto-Follow system indices #73237

Merged
merged 24 commits into from
Jun 29, 2021

Conversation

fcofdez
Copy link
Contributor

@fcofdez fcofdez commented May 19, 2021

This commits deprecates Auto-Follow of system indices

Relates #72815

@fcofdez fcofdez force-pushed the deprecate-auto-follow-system-indices branch from 121c403 to 9b8adc0 Compare May 25, 2021 08:22
@fcofdez fcofdez marked this pull request as ready for review May 25, 2021 11:38
@fcofdez fcofdez requested a review from henningandersen May 25, 2021 11:39

return new DeprecationIssue(DeprecationIssue.Level.WARNING,
"Some follower indices follow remote system indices",
"https://www.elastic.co/guide/en/elasticsearch/reference/master/breaking-changes-8.0.html",
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Where should I add the deprecation note?

Copy link
Contributor

Choose a reason for hiding this comment

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

I believe it should go to docs/reference/release-notes/7.14.asciidoc, you may need to add a reference from release-notes.asciidoc to it.

@fcofdez fcofdez added the Team:Distributed (Obsolete) Meta label for distributed team (obsolete). Replaced by Distributed Indexing/Coordination. label May 31, 2021
@elasticmachine
Copy link
Collaborator

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

@fcofdez fcofdez added :Distributed Indexing/CCR Issues around the Cross Cluster State Replication features v7.14.0 >breaking labels May 31, 2021
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.

I left a couple of comments.

Also, please fill in the PR description including links to the breaking change issue as well as any other relevant issues. Notice that the commit line length of the PR title is too long, should be max 50 characters.


package org.elasticsearch.xpack.core.ccr;

public class CCR {
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we should stick to conventions for Ccr elsewhere and use Ccr as the base name of the class. Also, I would prefer to call it CcrConstants just to distinguish it from the other Ccr class (which is the plugin, kind of defining the module).

@@ -135,6 +140,12 @@ private void createFollowerIndex(
return;
}

if (leaderIndexMetadata.isSystem()) {
deprecationLogger.deprecate(DeprecationCategory.INDICES,
Copy link
Contributor

Choose a reason for hiding this comment

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

This deprecation logging will fire on any explicit system index follow, whereas the breaking change in #72815 only skips auto-following system indices.

I would prefer to have the deprecation logging for auto-following only.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, that's something we need to discuss. Currently there's no way to know if a followed index request come from AutoFollow or from an explicit user request. I was wondering if we should add some extra metadata in order to distinguish the following origin, in that case existing followed system indices won't show up in the deprecation API. wdyt @henningandersen?

continue;
}
if (indexMetadata.isSystem()) {
systemIndexFollowers.add(indexEntry.key);
Copy link
Contributor

Choose a reason for hiding this comment

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

Same comment on the scope as above, we should only log deprecation issues when the index was originally auto-followed I think?

@fcofdez fcofdez changed the title [7.x] Add deprecation warning when a system index is followed [7.x] Add deprecation warnings for auto-followed system indices Jun 1, 2021
@fcofdez fcofdez changed the title [7.x] Add deprecation warnings for auto-followed system indices [7.x] Deprecate Auto-Follow system indices Jun 2, 2021
@fcofdez fcofdez requested a review from henningandersen June 2, 2021 09:45
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.

I left a few comments.


*Impact* +
In 8.0.0, remote system indices matching an <<ccr-auto-follow,auto-follow pattern>>
won't be configured as a follower index automatically.
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we should add a note on how to adapt to 8.0 behavior, by excluding patterns matching system indices like .tasks and .kibana-*.

@@ -196,6 +200,12 @@ private static void markExistingIndicesAsAutoFollowed(
for (final IndexMetadata indexMetadata : leaderMetadata) {
IndexAbstraction indexAbstraction = leaderMetadata.getIndicesLookup().get(indexMetadata.getIndex().getName());
if (AutoFollowPattern.match(patterns, indexAbstraction)) {
if (indexAbstraction.isSystem()) {
Copy link
Contributor

Choose a reason for hiding this comment

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

I am torn on this. I think the logic here ensures that we do not follow these existing system indices anyway and therefore it hardly makes sense to have the deprecation warning here? I would opt to remove it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

My thinking here was that we'll deprecate this behaviour in 7.14 but keep auto following system indices until 8.0. is that a misunderstanding on my side?

continue;
}
final String leaderIndexUUID = ccrMetadata.get(CcrConstants.CCR_CUSTOM_METADATA_LEADER_INDEX_UUID_KEY);
if (indexMetadata.isSystem() && followedLeaderIndexUUIDs.contains(leaderIndexUUID)) {
Copy link
Contributor

Choose a reason for hiding this comment

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

I were a bit surprised that isSystem() is true here, but I did not find the place where we would filter that out. I suppose it is correct, since it is sort of a restore. Would be nice to validate though in a test?

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 don't filter that metadata out. I'll add a test to validate it 👍

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You were right about this, the flag is lost when the index is "restored". I had to write a new checker that reaches the remote cluster to tell if the leader index was a system index. See CcrAutoFollowedSystemIndicesChecker and CcrAutoFollowInfoFetcher

import org.elasticsearch.xpack.ccr.CcrLicenseChecker;
import org.elasticsearch.xpack.ccr.CcrSettings;
import org.elasticsearch.xpack.core.ccr.AutoFollowMetadata;
import org.elasticsearch.xpack.core.ccr.AutoFollowMetadata.AutoFollowPattern;
import org.elasticsearch.xpack.core.ccr.AutoFollowStats;
import org.elasticsearch.xpack.core.ccr.CcrConstants;
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we should add a check to checkAutoFollowPattern to see if the leader index is a system index and output a deprecation warning if so?

(not related to the line the comment is on).

@fcofdez fcofdez requested a review from henningandersen June 9, 2021 16:03
@fcofdez
Copy link
Contributor Author

fcofdez commented Jun 23, 2021

@henningandersen would you mind reviewing this PR when you have the chance? Thanks!

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.

A few more comments, looking good otherwise.

@@ -132,11 +132,6 @@
public class Ccr extends Plugin implements ActionPlugin, PersistentTaskPlugin, EnginePlugin, RepositoryPlugin, ClusterPlugin {

public static final String CCR_THREAD_POOL_NAME = "ccr";
public static final String CCR_CUSTOM_METADATA_KEY = "ccr";
Copy link
Contributor

Choose a reason for hiding this comment

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

Perhaps leave a comment here, stating that these moved to CcrConstants in 7.x (since this targets 7.x only)?

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 b80e0e9

@@ -2154,6 +2155,114 @@ void cleanFollowedRemoteIndices(ClusterState remoteClusterState, List<String> pa
}
}

public void testDeprecationWarningsAreEmittedWhenASystemIndexIsAutoFollowed() throws Exception {
// Set up a mock log appender to watch for the log message we expect
Copy link
Contributor

Choose a reason for hiding this comment

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

This comment seems to be out of date.

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 b80e0e9 🤦

private static boolean isCurrentlyFollowed(PersistentTasksCustomMetadata persistentTasks, String indexName) {
return persistentTasks != null && persistentTasks.findTasks(ShardFollowTask.NAME, task -> true).stream()
.map(task -> (ShardFollowTask) task.getParams())
.anyMatch(shardFollowTask -> indexName.equals(shardFollowTask.getFollowShardId().getIndexName()));
Copy link
Contributor

Choose a reason for hiding this comment

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

Perhaps use Index rather than the index name, so that we compare both uuid and name.

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 b80e0e9


@Override
public void onFailure(Exception e) {
clusterResponsesListener.onFailure(e);
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this bails out of the deprecation check and I wonder if a remote cluster might not be somewhat expected to be unavailable sometimes. I wonder if we should instead present something about remote cluster not available in deprecation info?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The deprecation API doesn't provide a way to return fine grained error information. Currently the only thing we can do is return a DeprecationIssue but I would find a bit confusing to present an error about a remote cluster unavailability as a DeprecationIssue.

@fcofdez fcofdez requested a review from henningandersen June 28, 2021 16:40
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.

LGTM.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>breaking >deprecation :Distributed Indexing/CCR Issues around the Cross Cluster State Replication features Team:Distributed (Obsolete) Meta label for distributed team (obsolete). Replaced by Distributed Indexing/Coordination. v7.14.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants