Skip to content

KAFKA-13510: Connect APIs to list all connector plugins and retrieve …#11572

Merged
mimaison merged 6 commits intoapache:trunkfrom
mimaison:kip-769
Mar 3, 2022
Merged

KAFKA-13510: Connect APIs to list all connector plugins and retrieve …#11572
mimaison merged 6 commits intoapache:trunkfrom
mimaison:kip-769

Conversation

@mimaison
Copy link
Copy Markdown
Member

@mimaison mimaison commented Dec 7, 2021

…their configdefs

Implements KIP-769

Committer Checklist (excluded from commit message)

  • Verify design and implementation
  • Verify test coverage and CI build status
  • Verify documentation (including upgrade notes)

@mimaison mimaison force-pushed the kip-769 branch 2 times, most recently from dac03c6 to 62dd215 Compare December 13, 2021 17:56
@mimaison mimaison added connect kip Requires or implements a KIP labels Dec 13, 2021
@mimaison mimaison force-pushed the kip-769 branch 3 times, most recently from feda75b to 10e4b2f Compare February 21, 2022 21:39
@mimaison mimaison marked this pull request as ready for review February 21, 2022 21:46
@mimaison
Copy link
Copy Markdown
Member Author

@tombentley @vvcephei @C0urante As you voted on the KIP, can you take a look? Thanks

Copy link
Copy Markdown
Contributor

@C0urante C0urante left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread connect/api/src/main/java/org/apache/kafka/connect/storage/Converter.java Outdated
@mimaison
Copy link
Copy Markdown
Member Author

Thanks @C0urante for the review, all good suggestions. I believe I've addressed them all.

Copy link
Copy Markdown
Contributor

@C0urante C0urante left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@mimaison
Copy link
Copy Markdown
Member Author

Thanks @C0urante for the review! Again you made some very good suggestions. I've pushed an update.

Copy link
Copy Markdown
Contributor

@C0urante C0urante left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks Mickael! Looking forward to seeing this land in 3.2.

scanUrlsAndAddPlugins(
getParent(),
ClasspathHelper.forJavaClassPath().toArray(new URL[0]),
null
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, the "unused parameter" warning from my IDE has been bugging me here about this for ages 🙏

@C0urante
Copy link
Copy Markdown
Contributor

C0urante commented Feb 28, 2022

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.

@mimaison
Copy link
Copy Markdown
Member Author

mimaison commented Mar 1, 2022

@rhauch Can you take a look? It would be great to get this in 3.2. Thanks

Copy link
Copy Markdown
Member

@tombentley tombentley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few nits, but looks good, thanks!

}

@Override
public List<ConfigKeyInfo> connectorPluginConfig(String pluginName) {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should it really be called connectorPluginConfig when it handles other plugins too?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Contributor

@C0urante C0urante Mar 2, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I pushed an update to rename ConnectorPluginInfo to PluginInfo

Comment on lines 136 to 143
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;
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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),
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes me wonder why CONNECTOR was ever in this enum. Do you know @mimaison / @C0urante ?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be honest I'm not sure as it wasn't used by anything.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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()));
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it worth using Set.contains for this, rather than .equals and ||?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not really, I updated the logic to use equals and ||

@mimaison
Copy link
Copy Markdown
Member Author

mimaison commented Mar 2, 2022

Thanks @tombentley for the review! I've pushed an update.

Copy link
Copy Markdown
Member

@tombentley tombentley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks @mimaison!

@mimaison mimaison merged commit 029a14b into apache:trunk Mar 3, 2022
@mimaison mimaison deleted the kip-769 branch March 3, 2022 13:28
@mimaison
Copy link
Copy Markdown
Member Author

mimaison commented Mar 3, 2022

Thanks @C0urante and @tombentley for the reviews!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

connect kip Requires or implements a KIP

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants