Add a transport action to get the features of a node #110645
Conversation
elasticsearchmachine
added
Team:Core/Infra
|
Pinging @elastic/es-core-infra (Team:Core/Infra) |
There was a problem hiding this comment.
As mentioned in Slack I think we should consider this a TransportVersion change. I mean it does change the wire protocol, older nodes won't understand this action if we send it over the wire.
I'd also rather we added this action and its usage in one step. It kinda looks reasonable to me, but it's hard to be sure until you see how it's going to be used.
I left a couple of other inline comments.
| public ActionFuture<NodesFeaturesResponse> nodesFeatures(final NodesFeaturesRequest request) { | ||
| return execute(TransportNodesFeaturesAction.TYPE, request); | ||
| } | ||
|
|
||
| public void nodesFeatures(final NodesFeaturesRequest request, final ActionListener<NodesFeaturesResponse> listener) { | ||
| execute(TransportNodesFeaturesAction.TYPE, request, listener); | ||
| } | ||
|
|
There was a problem hiding this comment.
I would rather not add to this API, especially for an action which is so very specialized. Let's just invoke Client#execute directly as needed.
| import java.io.IOException; | ||
| import java.util.List; | ||
|
|
||
| @UpdateForV9 // this is not needed in v9+, all applicable versions support features |
There was a problem hiding this comment.
I expect it might be possible for a v8.last node might try and invoke this action on a v9+ node, so we'd need to preserve this until v10 even if it's unused in the v9 codebase.
| } | ||
|
|
||
| @Override | ||
| public XContentBuilder toXContent(XContentBuilder builder, Params params) throws IOException { |
There was a problem hiding this comment.
Why are we implementing toXContent for this response? We won't be exposing it to REST clients will we?
|
Implemented the whole lot in #110710 |
Whilst this is not currently used for anything, it will be used by a cluster state listener to fix node features in cluster state, in a similar way to
TransportVersionsFixupListener. This is separate to get it onto serverless before we deploy anything that uses it.Relates to #109254