Hi Greg,
> Applying this to a hypothetical extension of timeouts
> to other endpoints: my concern was primarily about
> whether this design applied everywhere felt natural or
> awkward. In my opinion, a request parameter would
> draw a lot of outsized attention in documentation, and
> be the first
Yash,
1. I think that Request-Timeout is a fine choice. I did not see any
standard header for a use-case like this, so we are free to choose a name
for ourselves.
2. While such proposals do not exist, I don't think that means that we
should exclude them from consideration. If we do, then we run t
Hi Greg,
Thanks for the response!
1. Hm that's a fair point, and while there aren't any strict guidelines or
rules governing whether something should be a query parameter versus a
request header, I agree that it might be more idiomatic for a request
timeout value to be accepted via a custom reque
Yash,
1.
Currently the request parameters in the REST API are individual and pertain
to just one endpoint.
They also change the content of the query result, or change the action
taken on the cluster.
I think that a request timeout is a property of the HTTP request more than
it is a property of the
Hi Greg,
Thanks for taking a look!
1. I believe Chris suggested the use of a query parameter above as we
already have precedents for using query parameters to configure per request
behavior in Kafka Connect (the restart connectors API and the get
connectors API for instance). Also, the limited ch
Hey Yash,
Thanks for the KIP, and sorry for the late review.
1. Have you considered a HTTP header to provide the client-configurable
timeout? A header might more naturally extend to all of the other endpoints
in the future, rather than duplicating the query parameter across endpoints.
2. I under
Hi all,
Thanks for all the feedback and discussion. I've renamed the KIP title to
"Kafka Connect REST API timeout improvements" since we're introducing a
couple of improvements (cancelling create / update connector requests when
config validations timeout and avoiding double config validations in
Hey Yash,
Thanks for the explanation. I think it should be fine to delegate the
validation directly to the leader.
Thanks!
Sagar.
On Sat, Nov 5, 2022 at 10:42 AM Yash Mayya wrote:
> Hi Sagar,
>
> Thanks for chiming in!
>
> > Having said that, why does the worker forward to the
> > leader? I am
Hi Sagar,
Thanks for chiming in!
> Having said that, why does the worker forward to the
> leader? I am thinking if the worker can perform the validation on it's
own,
> we could let it do the validation instead of forwarding everything to the
> leader
Only the leader is allowed to perform writes
Hi Chris,
Thanks again for your feedback. I think a worker configuration for the
upper bound makes sense - I initially thought we could hardcode it (just
like the current request timeout is), but there's no reason to set another
artificial bound that isn't user configurable which is exactly what w
Hey Yash,
Thanks for the KIP! This looks like a useful feature.
I think the discussion thread already has some great points by Chris. Just
a couple of points/clarifications=>
Regarding, pt#2 , I guess it might be better to forward to the leader as
suggested by Yash. Having said that, why does th
Hi Yash,
RE 2: That's a great point about validations already being performed by the
leader. For completeness's sake, I'd like to note that this only holds for
valid configurations; invalid ones are caught right now before being
forwarded to the leader. Still, I think it's fine to forward to the l
Hi Chris,
Thanks a lot for the super quick response and the great feedback!
1. I think that makes a lot of sense, and I'd be happy to update the KIP to
include this change in the scope. The current behavior where the API
response indicates a time out but the connector is created/updated
eventuall
Hi Yash,
Thanks for the KIP. It's a nice, focused change. Initially I was hesitant
to support cases where connector validation takes this long, but
considering the alternative is that we give users a 500 error response but
leave the request to create/modify the connector queued up in the herder, I
14 matches
Mail list logo
