This is a nice improvement, both from an operational standpoint as well as
for testing purposes, as we scale the number of connectors that a connect
cluster can run.
LGTM, thanks for the KIP Dan!
On Fri, May 3, 2019 at 2:50 PM Alex Liu wrote:
> Good question,
>
> `info` is probably the best
Good question,
`info` is probably the best name for it. The updated output on the wiki
looks reasonable to me.
Alex
On Fri, May 3, 2019 at 2:24 PM dan wrote:
> thanks. i think this make sense.
>
> i'm thinking we should just use repeated queryparams for this, so
> `?expand=status=config`
>
>
thanks. i think this make sense.
i'm thinking we should just use repeated queryparams for this, so
`?expand=status=config`
another thing is what do you think we should use for the `/` endpoint? was
thinking `?expand=info`
output could look like
w:kafka norwood$ curl -s '
Good idea, Dan. One thing I might suggest is to have the query parameters
reflect the fact that there are multiple resources under each connector.
There is `connectors//`, `connectors//config`, and
`connectors//status`.
Each of them returns a slightly different set of information, so it would
be
Thanks for the KIP, Dan! This is a simple change that will make it easier
to get the status of all of the connectors running in a Connect cluster,
and I like the approach of adding a query parameter to the existing
`connectors/` resource to be backward compatible and to avoid introducing
another
The intent of this KIP is to add a consolidate endpoint to connect that
gives consumers of the api a one stop shop for all their connector info
needs.
https://cwiki.apache.org/confluence/display/KAFKA/KIP-465%3A+Add+Consolidated+Connector+Endpoint+to+Connect+REST+API
thanks,
dan
