Maybe mark it abandoned?

fwiw, I think both KIPs break the worker-vs-connector boundary that, for
better or worse, is fundamental to Connect's architecture and APIs.

An alternative came up a few times during discussions for KIP-382: support
multiple "herders" within the same Connect cluster. Each herder would use a
separate worker config, and each would be addressable through the REST API
somehow. For example, perhaps you could POST a connector to a specific
herder, which would run the connector using that herder's worker config. In
most cases, you'd be fine with a single default herder, in which case
nothing would change from today's experience. But when necessary an
operator could add a new herder without creating an entirely new Connect
cluster. For example, you might have one herder with compression enabled
and one without.

Ryanne

On Fri, Mar 15, 2019 at 8:55 AM Randall Hauch <rha...@gmail.com> wrote:

>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-407%3A+Kafka+Connect+support+override+worker+kafka+api+configuration+with+connector+configuration+that+post+by+rest+api
> was created by the author and a discussion thread was never started.
>
> This appears to very similar to (or rather a subset of)
> https://issues.apache.org/jira/browse/KAFKA-6890 /
>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-296%3A+Connector+level+configurability+for+client+configs
> ,
> which IMO has the correct scope and where a discussion is taking place
> about the requirements and user experience. This proposal seems to differ
> from KAFKA-6890 / KIP-296 is that the approach proposed here only addresses
> connector configurations specified via the REST API, and not via
> configuration files passed to the standalone Connect worker. This would be
> a significant departure from the current behavior, where the REST API and
> file configurations are completely compatible.
>
> It's fine to leave this open for further discussion, but I would prefer to
> withdraw this KIP and instead focus the discussion on KIP-296.
>
> Thoughts?
>
> Randall
>

Reply via email to