-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
[7.x] Deprecate Auto-Follow system indices #73237
Conversation
121c403
to
9b8adc0
Compare
|
||
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", |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
Pinging @elastic/es-distributed (Team:Distributed) |
There was a problem hiding this 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 { |
There was a problem hiding this comment.
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, |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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?
There was a problem hiding this 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. |
There was a problem hiding this comment.
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()) { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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)) { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 👍
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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).
@henningandersen would you mind reviewing this PR when you have the chance? Thanks! |
There was a problem hiding this 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"; |
There was a problem hiding this comment.
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)?
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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())); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
This commits deprecates Auto-Follow of system indices
Relates #72815