You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »

This page is meant as a template for writing a KIP. To create a KIP choose Tools->Copy on this page and modify with your content and replace the heading with the next KIP number and a description of your issue. Replace anything in italics with your own description.

Status

Current state: Under Discussion

Discussion thread: here

JIRA: here [Change the link from KAFKA-1 to your own ticket]

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

Motivation

When starting a connector, users must provide the connector configuration. The configuration often also includes configurations for other plugins such as SMTs or converters. Today, Connect does not provide a way to see what plugins are available apart from connectors. This make it difficult for users building data pipeline to know which plugins are available and what is possible. Basically they have to know how the Connect runtime is set up. Even once they know the plugins that are available, they then have to go look at the plugins documentation or, in the worst case, look directly at the source code to find their configuration definitions.

Similarly, Kafka connect administrators want to know the plugins that are installed on each worker. This includes both REST Extensions and Config Providers plugins.

All plugins should be discoverable via the REST API. The configuration definitions of connector-level plugins should also be easily retrieved. This would significantly ease the process of building pipelines and enable building tools and UIs that can manage Connect data pipelines.

Public Interfaces

  • /connector-plugins: This endpoint will be updated to allow listing all plugins. A new query parameter "connectors_only" will be added and it will default to true so it's fully compatible with the current behavior. Users will be able to list all Connectors, Transformations, Converters, HeaderConverters and Predicates plugins by setting it to false.

For example GET /connector-plugins?connectors_only=false will return:

[
  {
    "class": "org.apache.kafka.connect.file.FileStreamSinkConnector",
    "type": "sink",
    "version": "3.0.0"
  },
  {
    "class": "org.apache.kafka.connect.converters.ByteArrayConverter",
    "type": "converter"
  },
  {
    "class": "org.apache.kafka.connect.transforms.Cast",
    "type": "transformation"
  },
  {
    "class": "org.apache.kafka.connect.transforms.predicates.HasHeaderKey",
    "type": "predicate"
  },
  {
    "class": "org.apache.kafka.connect.storage.SimpleHeaderConverter",
    "type": "header_converter"
  },
  ...
]


[
  {
    "name": "spec",
    "type": "LIST",
    "required": true,
    "default_value": null,
    "importance": "HIGH",
    "documentation": "List of fields and the type to cast them to of the form field1:type,field2:type to cast fields of Maps or Structs. A single type to cast the entire value. Valid types are int8, int16, int32, int64, float32, float64, boolean, and string. Note that binary fields can only be cast to string.",
    "group": null,
    "width": "NONE",
    "display_name": "spec",
    "dependents": [],
    "order": -1
  }
]


  • /worker-plugins: This new endpoint will list RestExtension and ConfigProvider plugins installed in the worker.
[
  {
    "class": "org.apache.kafka.connect.rest.basic.auth.extension.BasicAuthSecurityRestExtension",
    "type": "rest_extension",
    "version": "3.0.0"
  },
  {
    "class": "org.apache.kafka.common.config.provider.DirectoryConfigProvider",
    "type": "config_provider"
  },
  ...
]


Proposed Changes

REST API:

  • A new path will be added to ConnectorPluginsResource
@GET
@Path("/{plugin}/config")
public List<ConfigKeyInfo> getPluginConfig() {
    return doListPlugins();
}


  • Listing connector plugin will accept an optional query parameter "connectors_only"  that defaults to true
@GET
@Path("/")
public List<ConnectorPluginInfo> listConnectorPlugins(@DefaultValue("true") @QueryParam("connectors_only") boolean connectorsOnly) {
    return getConnectorPlugins(connectorsOnly);
}


  • A new REST resource named WorkerPluginsResource will be defined with a single endpoints to list worker plugins
@Path("/worker-plugins")
public class WorkerPluginsResource {
    @GET
    @Path("/")
    public List<WorkerPluginInfo> listPlugins() {}}


Converter interface:

Add a config() method to Converter. Also make it Configurable and Closeable so it's uniform with the other plugins:

public interface Converter extends Configurable, Closeable {

[...]

    /**
     * Configuration specification for this set of converters.
     * @return the configuration specification; may not be null
     */
    default ConfigDef config() {
        return new ConfigDef();
    }
}

It's common for custom converters to implement both Converter and HeaderConverter. As the 2 methods to retrieve the ConfigDef will have exactly the same signature, it will still be possible to implement both interfaces.

Compatibility, Deprecation, and Migration Plan

  • /connector-plugins keeps its current behavior and will only expose the new behavior when a new query parameter is set. I propose to flip the query parameter value in the next major release to list all plugins by default.
  • The other changes are new endpoints that don't cause compatibility issues.

Rejected Alternatives

  • Add a new endpoint /plugins for listing all plugins: It would be confusing to list both worker and connector plugins together. We'd then end up with 3 endpoints, /plugins, /worker-plugins and /connector-plugins which is as confusing!
  • Group connectors by type when listing them: This would break compatibility with the existing /connector-plugins behavior. As it's a very commonly used endpoint, it's preferred to keep compatibility.
  • No labels