More reliable trigger for security index migration#139028
Merged
tvernum merged 2 commits intoelastic:mainfrom Dec 4, 2025
Merged
More reliable trigger for security index migration#139028tvernum merged 2 commits intoelastic:mainfrom
tvernum merged 2 commits intoelastic:mainfrom
Conversation
We always want to trigger an index migration if one is required. However, we previously would only do that if we detected a change to the state of the security index on the master node. But a rolling upgrade might not cause a detectable change in index state - for example, in a cluster with dedicated masters nodes, if those nodes were upgraded last, then all index relocation would happen before the masters knew about the new migration (so they couldn't trigger it) and once the masters were upgraded they would detect that nothing had changed so never send a "security index changed" event and never trigger the migration task. Now, we say that if a security index exists, and it requires migration then it also triggers a change event
tvernum
added
>bug
:Security/Security
Collaborator
|
Pinging @elastic/es-security (Team:Security) |
Collaborator
|
Hi @tvernum, I've created a changelog YAML for you. |
jfreden
approved these changes
Dec 4, 2025
Contributor
jfreden
left a comment
jfreden
left a comment
There was a problem hiding this comment.
LGTM! Thanks for fixing this!
| return new ClusterChangedEvent("test-event", clusterState, EMPTY_CLUSTER_STATE); | ||
| } | ||
|
|
||
| public void testStateChangeListenerIsCalledIfMigrationIsRequired() { |
Contributor
There was a problem hiding this comment.
It would be nice to add an assertion in this test that makes sure that the listener isn't called if the migration is running and the state is unchanged, since that protects the listener from being called on every cluster state change until the target migration version has been applied.
Contributor
Author
There was a problem hiding this comment.
Fair, I can add that in a followup PR (or leave it to you if you want to get one in today).
I don't think we want to hold up the fix waiting for the test (since the code does check for an in-progress migration)
This was referenced Dec 4, 2025
Collaborator
💔 Backport failed
You can use sqren/backport to manually backport by running |
tvernum
added a commit
to tvernum/elasticsearch
that referenced
this pull request
Dec 4, 2025
We always want to trigger an index migration if one is required. However, we previously would only do that if we detected a change to the state of the security index on the master node. But a rolling upgrade might not cause a detectable change in index state - for example, in a cluster with dedicated masters nodes, if those nodes were upgraded last, then all index relocation would happen before the masters knew about the new migration (so they couldn't trigger it) and once the masters were upgraded they would detect that nothing had changed so never send a "security index changed" event and never trigger the migration task. Now, we say that if a security index exists, and it requires migration then it also triggers a change event
tvernum
added a commit
to tvernum/elasticsearch
that referenced
this pull request
Dec 4, 2025
We always want to trigger an index migration if one is required. However, we previously would only do that if we detected a change to the state of the security index on the master node. But a rolling upgrade might not cause a detectable change in index state - for example, in a cluster with dedicated masters nodes, if those nodes were upgraded last, then all index relocation would happen before the masters knew about the new migration (so they couldn't trigger it) and once the masters were upgraded they would detect that nothing had changed so never send a "security index changed" event and never trigger the migration task. Now, we say that if a security index exists, and it requires migration then it also triggers a change event
jfreden
pushed a commit
to jfreden/elasticsearch
that referenced
this pull request
Dec 4, 2025
We always want to trigger an index migration if one is required. However, we previously would only do that if we detected a change to the state of the security index on the master node. But a rolling upgrade might not cause a detectable change in index state - for example, in a cluster with dedicated masters nodes, if those nodes were upgraded last, then all index relocation would happen before the masters knew about the new migration (so they couldn't trigger it) and once the masters were upgraded they would detect that nothing had changed so never send a "security index changed" event and never trigger the migration task. Now, we say that if a security index exists, and it requires migration then it also triggers a change event
elasticsearchmachine
pushed a commit
that referenced
this pull request
Dec 4, 2025
We always want to trigger an index migration if one is required. However, we previously would only do that if we detected a change to the state of the security index on the master node. But a rolling upgrade might not cause a detectable change in index state - for example, in a cluster with dedicated masters nodes, if those nodes were upgraded last, then all index relocation would happen before the masters knew about the new migration (so they couldn't trigger it) and once the masters were upgraded they would detect that nothing had changed so never send a "security index changed" event and never trigger the migration task. Now, we say that if a security index exists, and it requires migration then it also triggers a change event
elasticsearchmachine
pushed a commit
that referenced
this pull request
Dec 4, 2025
We always want to trigger an index migration if one is required. However, we previously would only do that if we detected a change to the state of the security index on the master node. But a rolling upgrade might not cause a detectable change in index state - for example, in a cluster with dedicated masters nodes, if those nodes were upgraded last, then all index relocation would happen before the masters knew about the new migration (so they couldn't trigger it) and once the masters were upgraded they would detect that nothing had changed so never send a "security index changed" event and never trigger the migration task. Now, we say that if a security index exists, and it requires migration then it also triggers a change event Co-authored-by: Tim Vernum <tim@adjective.org>
jfreden
pushed a commit
to jfreden/elasticsearch
that referenced
this pull request
Dec 4, 2025
We always want to trigger an index migration if one is required. However, we previously would only do that if we detected a change to the state of the security index on the master node. But a rolling upgrade might not cause a detectable change in index state - for example, in a cluster with dedicated masters nodes, if those nodes were upgraded last, then all index relocation would happen before the masters knew about the new migration (so they couldn't trigger it) and once the masters were upgraded they would detect that nothing had changed so never send a "security index changed" event and never trigger the migration task. Now, we say that if a security index exists, and it requires migration then it also triggers a change event (cherry picked from commit ac2e0b0) # Conflicts: # x-pack/plugin/security/src/main/java/org/elasticsearch/xpack/security/support/SecurityIndexManager.java # x-pack/plugin/security/src/test/java/org/elasticsearch/xpack/security/support/SecurityIndexManagerTests.java
Contributor
💚 All backports created successfully
Questions ?Please refer to the Backport tool documentation |
elasticsearchmachine
pushed a commit
that referenced
this pull request
Dec 4, 2025
We always want to trigger an index migration if one is required. However, we previously would only do that if we detected a change to the state of the security index on the master node. But a rolling upgrade might not cause a detectable change in index state - for example, in a cluster with dedicated masters nodes, if those nodes were upgraded last, then all index relocation would happen before the masters knew about the new migration (so they couldn't trigger it) and once the masters were upgraded they would detect that nothing had changed so never send a "security index changed" event and never trigger the migration task. Now, we say that if a security index exists, and it requires migration then it also triggers a change event
jfreden
added a commit
that referenced
this pull request
Dec 4, 2025
We always want to trigger an index migration if one is required. However, we previously would only do that if we detected a change to the state of the security index on the master node. But a rolling upgrade might not cause a detectable change in index state - for example, in a cluster with dedicated masters nodes, if those nodes were upgraded last, then all index relocation would happen before the masters knew about the new migration (so they couldn't trigger it) and once the masters were upgraded they would detect that nothing had changed so never send a "security index changed" event and never trigger the migration task. Now, we say that if a security index exists, and it requires migration then it also triggers a change event (cherry picked from commit ac2e0b0) # Conflicts: # x-pack/plugin/security/src/main/java/org/elasticsearch/xpack/security/support/SecurityIndexManager.java # x-pack/plugin/security/src/test/java/org/elasticsearch/xpack/security/support/SecurityIndexManagerTests.java Co-authored-by: Tim Vernum <tim@adjective.org>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
We always want to trigger an index migration if one is required.
However, we previously would only do that if we detected a change to the state of the security index on the master node. But a rolling upgrade might not cause a detectable change in index state - for example, in a cluster with dedicated masters nodes, if those nodes were upgraded last, then all index relocation would happen before the masters knew about the new migration (so they couldn't trigger it) and once the masters were upgraded they would detect that nothing had changed so never send a "security index changed" event and never trigger the migration task.
Now, we say that if a security index exists, and it requires migration then it also triggers a change event