-
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
Add API for resetting state of a SystemIndexPlugin
#69469
Add API for resetting state of a SystemIndexPlugin
#69469
Conversation
My initial cut used a TransportMasterNodeAction, which requires code that carefully manipulates cluster state. At least for the first cut and testing, it seems like it will be much easier to use a client within a HandledTransportAction, which effectively makes the TransportResetFeatureStateAction a class that dispatches other transport actions to do the real work. This could leave cleanup vulnerable to interference from other actions, e.g., indices deleted between lookup and deletion actions, but I can try to tighten that up at a later stage if I need to.
I still have some TODOs scattered in the code. I'll keep working on those, but I'm interested in feedback on the overall approach. |
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.
Left a couple comments, approach looks good though. Nice work!
...r/src/main/java/org/elasticsearch/rest/action/admin/cluster/RestResetFeatureStateAction.java
Outdated
Show resolved
Hide resolved
client/rest-high-level/src/main/java/org/elasticsearch/client/FeaturesClient.java
Show resolved
Hide resolved
client/rest-high-level/src/main/java/org/elasticsearch/client/FeaturesClient.java
Show resolved
Hide resolved
client/rest-high-level/src/main/java/org/elasticsearch/client/FeaturesRequestConverters.java
Outdated
Show resolved
Hide resolved
...java/org/elasticsearch/action/admin/cluster/snapshots/features/ResetFeatureStateRequest.java
Outdated
Show resolved
Hide resolved
List<String> systemIndices = indexDescriptors.stream() | ||
.map(sid -> sid.getMatchingIndices(clusterService.state().getMetadata())) | ||
.flatMap(List::stream) | ||
.collect(Collectors.toList()); | ||
|
||
List<String> associatedIndices = new ArrayList<>(associatedIndexPatterns); | ||
|
||
List<String> allIndices = Stream.concat(systemIndices.stream(), associatedIndices.stream()) | ||
.collect(Collectors.toList()); |
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.
List<String> systemIndices = indexDescriptors.stream() | |
.map(sid -> sid.getMatchingIndices(clusterService.state().getMetadata())) | |
.flatMap(List::stream) | |
.collect(Collectors.toList()); | |
List<String> associatedIndices = new ArrayList<>(associatedIndexPatterns); | |
List<String> allIndices = Stream.concat(systemIndices.stream(), associatedIndices.stream()) | |
.collect(Collectors.toList()); | |
Stream<String> systemIndices = indexDescriptors.stream() | |
.map(sid -> sid.getMatchingIndices(clusterService.state().getMetadata())) | |
.flatMap(List::stream); | |
List<String> allIndices = Stream.concat(systemIndices, associatedIndexPatterns.stream()) | |
.collect(Collectors.toUnmodifiableList()); |
We're unnecessarily creating objects here, so I provided a suggestion to clean it up. Also should associatedIndexPatterns be resolved from patterns to 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.
I made the suggested change, but you're probably right about associatedIndexPatterns. I'll take a look and report back.
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 works as written, because we can pass a valid index pattern to the delete request, which will then handle the resolution logic when executed. We can't do the same thing with system index descriptor patterns because they can use character-class regexes, for example .test-[ab]*
.
It might be worth resolving the associated indices here so that we can skip submitting the delete request when no indices exist. Do you think this is important to do?
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 it is fine as it is unless we discover issues
server/src/main/java/org/elasticsearch/indices/SystemIndices.java
Outdated
Show resolved
Hide resolved
Out of an abundance of caution, I think the "reset" part of this path should have a leading underscore, so that if there's ever a reason to implement "GET _features/<feature_id>" we won't have to worry about distinguishing "reset" from a feature 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.
LGTM
@elasticmachine update branch |
@elasticmachine run elasticsearch-ci/1 |
When we disable access to system indices, plugins will still need a way to erase their state. The obvious and most pressing use case for this is in tests, which need to be able to clean up the state of a cluster in between groups of tests. * Use a HandledTransportAction for reset action My initial cut used a TransportMasterNodeAction, which requires code that carefully manipulates cluster state. At least for the first cut and testing, it seems like it will be much easier to use a client within a HandledTransportAction, which effectively makes the TransportResetFeatureStateAction a class that dispatches other transport actions to do the real work. * Clean up code by using a GroupedActionListener * ML feature state cleaner * Implement Transform feature state reset * Change _features/reset path to _features/_reset Out of an abundance of caution, I think the "reset" part of this path should have a leading underscore, so that if there's ever a reason to implement "GET _features/<feature_id>" we won't have to worry about distinguishing "reset" from a feature name. Co-authored-by: Gordon Brown <[email protected]> Co-authored-by: Elastic Machine <[email protected]>
Pinging @elastic/es-core-infra (Team:Core/Infra) |
* Add API for resetting state of a `SystemIndexPlugin` (#69469) When we disable access to system indices, plugins will still need a way to erase their state. The obvious and most pressing use case for this is in tests, which need to be able to clean up the state of a cluster in between groups of tests. * Use a HandledTransportAction for reset action My initial cut used a TransportMasterNodeAction, which requires code that carefully manipulates cluster state. At least for the first cut and testing, it seems like it will be much easier to use a client within a HandledTransportAction, which effectively makes the TransportResetFeatureStateAction a class that dispatches other transport actions to do the real work. * Clean up code by using a GroupedActionListener * ML feature state cleaner * Implement Transform feature state reset * Change _features/reset path to _features/_reset Out of an abundance of caution, I think the "reset" part of this path should have a leading underscore, so that if there's ever a reason to implement "GET _features/<feature_id>" we won't have to worry about distinguishing "reset" from a feature name. Co-authored-by: Gordon Brown <[email protected]> Co-authored-by: Elastic Machine <[email protected]>
Backport to 7.x: #70524 |
When we disable access to system indices, plugins will still need a way to erase their state. The obvious and most pressing use case for this is in tests, which need to be able to clean up the state of a cluster in between groups of tests.
In this first draft of the feature state reset API, a user with snapshot admin privileges
POST
s a request to/_reset_feature_state
. The node handling the endpoint then iterates through a list of features and executes their cleanup callbacks. By default, these callbacks use a client and a clusterState to delete all system indexes and associated indexes for a feature. The endpoint then returns a list of objects that include a feature name and a report of whether the reset operation succeeded or failed.