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 <alex....@confluent.io> wrote: > 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 <dan.norw...@gmail.com> wrote: > > > 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:8083/connectors?expand=status&expand=config' | jq > > > > { > > > > "blah": { > > > > "config": { > > > > "name": "blah", > > > > "config": { > > > > "connector.class": > > "org.apache.kafka.connect.file.FileStreamSourceConnector", > > > > "file": "/tmp/lol", > > > > "tasks.max": "10", > > > > "name": "blah", > > > > "topic": "test-topic" > > > > }, > > > > "tasks": [ > > > > { > > > > "connector": "blah", > > > > "task": 0 > > > > } > > > > ], > > > > "type": "source" > > > > }, > > > > "status": { > > > > "name": "blah", > > > > "connector": { > > > > "state": "RUNNING", > > > > "worker_id": "10.200.25.241:8083" > > > > }, > > > > "tasks": [ > > > > { > > > > "id": 0, > > > > "state": "RUNNING", > > > > "worker_id": "10.200.25.241:8083" > > > > } > > > > ], > > > > "type": "source" > > > > } > > > > } > > > > } > > > > > > will update the wiki with this info > > > > thanks > > dan > > > > On Thu, May 2, 2019 at 4:43 PM Alex Liu <alex....@confluent.io> wrote: > > > > > 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/<name>/`, `connectors/<name>/config`, and > > > `connectors/<name>/status`. > > > Each of them returns a slightly different set of information, so it > would > > > be useful to allow the query parameter be a string instead of a > > true/false > > > flag. In this case, `expand=status,config` would specify expanding both > > the > > > /status and /config subresources into the response objects. > > > > > > Other than this detail, I think this is a useful addition to the > Connect > > > REST API. > > > > > > Alex > > > > > >
