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 na
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&expand=config
thanks. i think this make sense.
i'm thinking we should just use repeated queryparams for this, so
`?expand=status&expand=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 '
http://localhost
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 us
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 re
