I'd like to keep the scope pretty tight -- getting SMTs is the real
motivation here.
If you think deprecation of the existing `/connector-plugins` endpoint
necessitates expanding the scope to re-thinking a new top-level API and the
implications for every subtype, then I think the right move here i
That's a valid point based on what the implementation is today. But this
new endpoint aims to be an extension and a superset in terms of
functionality of the existing `/connector-plugins` endpoint.
This last discussion and the fact that the endpoint `/plugins/connector`
that you suggest is almost
Since it is just two endpoints, I agree it's fine to move them over.
However, the endpoint you suggest would imply that someone could attempt to
validate the configs of an SMT or Header Converter, since it doesn't
specify the plugin's type. So if you agree I'll update the proposal to move
the PUT
Hi Cyrus,
Given that `/connector-plugins` is a top level endpoint, I think the
suggestion to deprecate `/connector-plugins` should affect all the nested
endpoints.
This should be straightforward here (in terms of KIP changes but also
implementation), because the endpoints are only two:
GET /conn
I wasn't trying to suggest deprecating all verbs and endpoints prefixed
with `/connector-plugins`, just the `GET: /connector-plugins` as I detailed
in the KIP. Maybe I'm not understanding your recommendation, or there's a
way I can make the KIP text clearer? Or do you disagree this is the right
m
Thanks for the response Cyrus.
If we are suggesting deprecation of `/connector-plugins` in favor of
`/plugins` I think we should mention explicitly that the new endpoint
covers the existing functionality precisely, including the validation
endpoint for connector plugins.
I'd recommend extending th
I will move to vote
On Mon, Jun 7, 2021 at 10:44 AM Cyrus Vafadari wrote:
> Thanks for the feedback,
>
> I added an example request/response for SMTs, and I thought about your
> suggestion re:deprecation and am now explicitly proposing to mark the
> existing endpoint as deprecated, though I don'
Thanks for the feedback,
I added an example request/response for SMTs, and I thought about your
suggestion re:deprecation and am now explicitly proposing to mark the
existing endpoint as deprecated, though I don't anticipate the need to
remove it will arise any time soon!
Cyrus
On Fri, Jun 4, 20
Hi Cyrus.
The proposal looks good and I like the API spec definition the way it's
presented.
Having said that, a few examples that would list the request type and body,
the returned status and the json response would be nice too, following the
tradition of other KIPs.
See
https://cwiki.apache.or
Thanks! Anyone else from the community with final thoughts before going to
vote?
On Mon, Apr 19, 2021 at 4:16 AM Tom Bentley wrote:
> Hi Cyrus,
>
> That seems reasonable to me.
>
> On Thu, Apr 15, 2021 at 6:44 PM Cyrus Vafadari
> wrote:
>
> > What do you think of "type" field remaining in, and
Hi Cyrus,
That seems reasonable to me.
On Thu, Apr 15, 2021 at 6:44 PM Cyrus Vafadari wrote:
> What do you think of "type" field remaining in, and returning
> "transformation", "converter" or whatever type it is. This way the schema
> remains consistent, and you can programmatically understand
What do you think of "type" field remaining in, and returning
"transformation", "converter" or whatever type it is. This way the schema
remains consistent, and you can programmatically understand what plugins
are returned on the holistic "GET /plugins" endpoint? It will be slightly
redundant in the
Hi Cyrus,
Re 2: A very minor thing but while type=source|sink for a connector, it
doesn't makes sense for the other plugin types, but so the json for those
plugins should omit that property rather than have type=null.
Apart from that it seems reasonable to me. Thanks again,
Tom
On Thu, Apr 15,
Hi Tom,
Thanks for taking the time to respond with thoughtful questions:
1. I propose HTTP-400, will update the KIP to reflect this proposal
2. I think the schema should be of the same format. It is quite minimal, so
there is room to add fields in the future without breaking compatibility.
I will
Hi Cyrus,
Thanks for the KIP. A few questions:
1. What status code does the /plugins/{plugin-type} endpoint return when an
unknown type is given?
2. The result of /connector-plugins is a list of objects with 'class',
'type' and 'version' properties. Presumably /plugins/connector is the same,
but
Hello all,
As the number of connect plugins, SMT's, etc have grown, I wanted to bump
this thread to see if there is more interest in adding a Connect REST
endpoint to get the current plugins in the worker.
Thanks all, and thanks Chris for the initial feedback on this.
On Mon, Feb 17, 2020 at 12:
Thanks for the feedback, Chris.
WRT Worker-plugins, I see your point that they aren't very useful for
people trying to create connectors to see what exists already, but I would
find them useful for things like making assertions against a docker image
to confirm the pluginpaths/classpaths are confi
Hi Cyrus,
Thanks for the KIP!
One quick question--I see the use case for being able to list per-connector
plugins (SMTs, converters, and header converters) via REST API, but I'm not
so sure about worker plugins (REST extensions and config providers). Since
those are configured at startup for the
I've updated the KIP here to simplify and clarify the goal -- it's a pretty
simple KIP to add a REST endpoint for SMTs and other plugins. This will
make it easier to see what SMTs you've loaded.
Hoping for some good discussion!
Thanks, all
On Sat, Jul 20, 2019 at 9:07 PM Cyrus Vafadari wrote:
Hello, all,
I'd like to start discussion on a new KIP I'm proposing to add HTTP
endpoints to Kafka Connect to give us some more insight into other
non-connector plugins, like Simple Message Transformations (SMTs). The KIP
would not change how Connect works in any meaningful way except to expose
so
20 matches
Mail list logo
