migrate more actions to protocol.xpack #32892
Conversation
this PR creates client-side instances of the following actions: - DeleteAction - ForceMergeAction - ReadOnlyAction - RolloverAction - ForceMergeAction ShrinkAction and AllocateAction are done separately
talevy
added
the
:Data Management/ILM+SLM
|
hey all. I've requested review. but I guess this review should be pending the review for Allocate Action since I want that one to govern how the rest of these are brought into the client |
colings86
left a comment
colings86
left a comment
There was a problem hiding this comment.
Same comments as the allocate action PR but I think this is good otherwise so we can apply the same fixes to both PRs 😄
| org.elasticsearch.protocol.xpack.indexlifecycle.RolloverAction::parse), | ||
| new NamedXContentRegistry.Entry(org.elasticsearch.protocol.xpack.indexlifecycle.ShrinkAction.class, | ||
| new ParseField(org.elasticsearch.protocol.xpack.indexlifecycle.ShrinkAction.NAME), | ||
| org.elasticsearch.protocol.xpack.indexlifecycle.ShrinkAction::parse) |
There was a problem hiding this comment.
Same comment here as in the allocate action PR about needing a common categoryClass for all the actions so we can deserialise them without knowing the exact action type and also same comment about moving the registration of the server side objects away from the client.
|
|
||
| /** | ||
| * Parent class for the client-side ilm actions for the {@link NamedXContentRegistry} | ||
| */ |
There was a problem hiding this comment.
Same comment as in http://github.com/elastic/elasticsearch/pull/32853
this PR creates client-side instances of the following actions: - DeleteAction - ForceMergeAction - ReadOnlyAction - RolloverAction - ForceMergeAction AllocateAction was done separately
2 participants
this PR creates client-side instances of the following actions:
AllocateAction can be found here (#32853)