config: make PUT to /cluster_config friendlier by waiting for status updates #5833
Labels
Comments
jcsp
added a commit
to jcsp/redpanda
that referenced
this issue
Aug 4, 2022
Previously, after writing a config update, API clients could do a /status query to the same node and not see any nodes (including the leader that they just PUT to) reflect the new version. With this change, if the client is talking to the controller leader, it will reliably see the new config version reflected in the /status result when querying the same node again after a PUT. This is a little subtle and later we should make simpler rules for this via a higher level "wait for status updates" as part of the PUT call itself: redpanda-data#5833 Related: redpanda-data#5609
vbotbuildovich
pushed a commit
to vbotbuildovich/redpanda
that referenced
this issue
Aug 16, 2022
Previously, after writing a config update, API clients could do a /status query to the same node and not see any nodes (including the leader that they just PUT to) reflect the new version. With this change, if the client is talking to the controller leader, it will reliably see the new config version reflected in the /status result when querying the same node again after a PUT. This is a little subtle and later we should make simpler rules for this via a higher level "wait for status updates" as part of the PUT call itself: redpanda-data#5833 Related: redpanda-data#5609 (cherry picked from commit 6ba1128)
vbotbuildovich
pushed a commit
to vbotbuildovich/redpanda
that referenced
this issue
Aug 16, 2022
Previously, after writing a config update, API clients could do a /status query to the same node and not see any nodes (including the leader that they just PUT to) reflect the new version. With this change, if the client is talking to the controller leader, it will reliably see the new config version reflected in the /status result when querying the same node again after a PUT. This is a little subtle and later we should make simpler rules for this via a higher level "wait for status updates" as part of the PUT call itself: redpanda-data#5833 Related: redpanda-data#5609 (cherry picked from commit 6ba1128)
felixguendling
pushed a commit
to felixguendling/redpanda
that referenced
this issue
Aug 22, 2022
Previously, after writing a config update, API clients could do a /status query to the same node and not see any nodes (including the leader that they just PUT to) reflect the new version. With this change, if the client is talking to the controller leader, it will reliably see the new config version reflected in the /status result when querying the same node again after a PUT. This is a little subtle and later we should make simpler rules for this via a higher level "wait for status updates" as part of the PUT call itself: redpanda-data#5833 Related: redpanda-data#5609
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
via #5609 (comment)
Currently, when you write new config and get a config version in the response, there is no guarantee that a subsequent GET to cluster_config/status on the same node will reflect the new version in that node's status.
To simplify API clients, it probably makes sense to have a wait+timeout on propagation of status, perhaps to all up nodes, not just the one handling the request. That way, a typical API client wouldn't need to do the "set and then wait for status" loop on the client side, at least in the healthy cluster case where the wait for status doesn't time out. if it does time out, we should still give a 200 response to the config update: if callers want to disambiguate this response to know whether config was really applied to all nodes, they can fall back to doing the polling of /status.
JIRA Link: CORE-990
The text was updated successfully, but these errors were encountered: