KAFKA-13510: Connect APIs to list all connector plugins and retrieve …#11572
KAFKA-13510: Connect APIs to list all connector plugins and retrieve …#11572mimaison merged 6 commits intoapache:trunkfrom
Conversation
dac03c6 to
62dd215
Compare
feda75b to
10e4b2f
Compare
|
@tombentley @vvcephei @C0urante As you voted on the KIP, can you take a look? Thanks |
C0urante
left a comment
There was a problem hiding this comment.
Thanks @mimaison. I've taken a pass at all of the functional parts; leaving the testing logic for later. Feel free to ignore (and resolve) anything prefaced with "nit" without commenting if you don't want to address it for whatever reason.
|
Thanks @C0urante for the review, all good suggestions. I believe I've addressed them all. |
C0urante
left a comment
There was a problem hiding this comment.
Looking good! I've completed a pass of every file, including test cases. Once everything here is addressed (with code changes or discussion) I think this will be ready to go.
|
Thanks @C0urante for the review! Again you made some very good suggestions. I've pushed an update. |
C0urante
left a comment
There was a problem hiding this comment.
LGTM, thanks Mickael! Looking forward to seeing this land in 3.2.
| scanUrlsAndAddPlugins( | ||
| getParent(), | ||
| ClasspathHelper.forJavaClassPath().toArray(new URL[0]), | ||
| null |
There was a problem hiding this comment.
Thanks, the "unused parameter" warning from my IDE has been bugging me here about this for ages 🙏
|
Noticed that the "resolve comment" option isn't available on this PR, apparently you need to either be the author of a PR or have write access to the repo in order to resolve comments (ref). Feel free to resolve everything from me if you'd like; might help reduce noise on this page for other reviewers. |
|
@rhauch Can you take a look? It would be great to get this in 3.2. Thanks |
tombentley
left a comment
There was a problem hiding this comment.
A few nits, but looks good, thanks!
| } | ||
|
|
||
| @Override | ||
| public List<ConfigKeyInfo> connectorPluginConfig(String pluginName) { |
There was a problem hiding this comment.
Should it really be called connectorPluginConfig when it handles other plugins too?
There was a problem hiding this comment.
In this context we consider connectors, transforms, converters, etc as "connector plugins" as opposed to "worker plugins" such as config providers and rest extensions.
With that in mind, do you think it's still worth naming this method and ConnectorPluginInfo?
There was a problem hiding this comment.
If we continue to put the onus on the Herder to ensure that the requested plugin has a supported type (e.g., throw an error if it's a REST extension), then I think "connector plugin" is useful since it differentiates between worker and connector plugins.
But it looks like the ConnectorPluginInfo class is itself completely agnostic on the connector-plugin vs. worker-plugin front, and it might even be possible to leverage it with no modifications if we eventually decide to add support for exposing worker plugin information to the REST API. So I think renaming that to PluginInfo (or something like that) would be reasonable.
There was a problem hiding this comment.
I pushed an update to rename ConnectorPluginInfo to PluginInfo
| Set<PluginDesc<Connector>> connectors = new TreeSet<>(); | ||
| for (PluginDesc<SinkConnector> sinkConnector : sinkConnectors) { | ||
| connectors.add((PluginDesc<Connector>) (PluginDesc<? extends Connector>) sinkConnector); | ||
| } | ||
| for (PluginDesc<SourceConnector> sourceConnector : sourceConnectors) { | ||
| connectors.add((PluginDesc<Connector>) (PluginDesc<? extends Connector>) sourceConnector); | ||
| } | ||
| return connectors; |
There was a problem hiding this comment.
| Set<PluginDesc<Connector>> connectors = new TreeSet<>(); | |
| for (PluginDesc<SinkConnector> sinkConnector : sinkConnectors) { | |
| connectors.add((PluginDesc<Connector>) (PluginDesc<? extends Connector>) sinkConnector); | |
| } | |
| for (PluginDesc<SourceConnector> sourceConnector : sourceConnectors) { | |
| connectors.add((PluginDesc<Connector>) (PluginDesc<? extends Connector>) sourceConnector); | |
| } | |
| return connectors; | |
| Set<PluginDesc<Connector>> connectors = new TreeSet<>((Set) sinkConnectors); | |
| connectors.addAll((Set) sourceConnectors); | |
| return connectors; |
| public enum PluginType { | ||
| SOURCE(SourceConnector.class), | ||
| SINK(SinkConnector.class), | ||
| CONNECTOR(Connector.class), |
There was a problem hiding this comment.
To be honest I'm not sure as it wasn't used by anything.
There was a problem hiding this comment.
I think it allowed for classes that subclassed Connector but didn't subclass from SinkConnector or SourceConnector to still be detected by the worker during plugin scanning and included in responses for the /connector-plugins endpoint, with a type of UNKNOWN.
With this change, those kinds of connector classes won't appear in the response for this endpoint anymore.
I think this should be fine. As of #2604, which was merged over a year ago, it's impossible to create that kind of connector anyways.
|
|
||
| import java.util.Objects; | ||
|
|
||
| public class ConnectorPluginInfo { |
There was a problem hiding this comment.
Should the name remain as ConnectorPluginInfo when it's no longer just for connector plugins?
| synchronized (this) { | ||
| if (connectorsOnly) { | ||
| Set<String> types = new HashSet<>(Arrays.asList(PluginType.SINK.toString(), PluginType.SOURCE.toString())); | ||
| return Collections.unmodifiableList(connectorPlugins.stream().filter(p -> types.contains(p.type())).collect(Collectors.toList())); |
There was a problem hiding this comment.
Is it worth using Set.contains for this, rather than .equals and ||?
There was a problem hiding this comment.
Not really, I updated the logic to use equals and ||
|
Thanks @tombentley for the review! I've pushed an update. |
|
Thanks @C0urante and @tombentley for the reviews! |
…their configdefs
Implements KIP-769
Committer Checklist (excluded from commit message)