Add OperatorHandler interface #87767
Conversation
grcevski
added
>non-issue
:Core/Infra/Core
|
Pinging @elastic/es-core-infra (Team:Core/Infra) |
|
@elasticmachine update branch |
| * @param service A templated service class to look for providers in plugins | ||
| * @return an immutable {@link List} of discovered providers in the plugins/modules | ||
| */ | ||
| public <T> List<? extends T> loadServiceProviders(Class<T> service) { |
There was a problem hiding this comment.
Can this be split out into a separate PR? It seems like this is most of this PR, but the title would suggest otherwise.
There was a problem hiding this comment.
Yes, sounds good, I'll take this out from this PR and contribute it back once the operator handler interface is in.
There was a problem hiding this comment.
This looks good at a high level. The three methods, name, transform and dependencies make sense. One general comment on the javadocs are that they should generally have a clear one sentence explanation about what the method does. Currently these methods all have large blocks of text that are a good explanation, but they are too detailed for the quick summary that should be the first, separate, line.
| * @param source the operator content as a map | ||
| * @return | ||
| */ | ||
| default XContentParser mapToXContentParser(XContentParserConfiguration config, Map<String, ?> source) { |
There was a problem hiding this comment.
This doesn't seem to have anything to do with operator config, could it be in a more general place for xcontent utilities?
| * @return | ||
| */ | ||
| @SuppressWarnings("unchecked") | ||
| default Map<String, ?> asMap(Object input) { |
There was a problem hiding this comment.
This doesn't seem like something specific to operator config, could it be in a more appropriate location for utility methods?
| * | ||
| * @param request the master node request that we base this operator handler on | ||
| */ | ||
| default void validate(MasterNodeRequest<?> request) { |
There was a problem hiding this comment.
Does this differ across any operator handler implementations? If not, could it just be a local utility method in the operator code?
grcevski
changed the title
This PR relates to #86224 (Operator/File cluster settings). We are introducing a new action handler interface called OperatorHandler, which will be used to implement various operator mode actions to update the cluster state. Since handlers can belong to modules and plugins, we introduce a SPI to declare the handlers a plugin/module provides.
For reference, please see OperatorLifecycleAction.java in #86224.
Since the original PR is too large on its own, I'm separating the individual components of the PR for easier review.