Bump Khepri to 0.17.0 #12753
Bump Khepri to 0.17.0 #12753
Conversation
the-mikedavis
force-pushed
the
md/khepri-0-17
branch
3 times, most recently
from
6d289fe to
cc6185d
Compare
the-mikedavis
force-pushed
the
md/khepri-0-17
branch
6 times, most recently
from
5cb0a79 to
42f571a
Compare
the-mikedavis
force-pushed
the
md/khepri-0-17
branch
3 times, most recently
from
17e7652 to
d4c49f2
Compare
the-mikedavis
force-pushed
the
md/khepri-0-17
branch
3 times, most recently
from
8caf8c0 to
8efd8ca
Compare
the-mikedavis
force-pushed
the
md/khepri-0-17
branch
from
8efd8ca to
3b09f4c
Compare
|
Thank you for updating the branch! I’m working on updating Ra in Khepri but there are small changes of behaviors that cause test flakes. I fixed one of them (Ra can reture |
|
I fixed the bug in Do you think we can update Khepri in RabbitMQ now? Perhaps we should focus on that and release Khepri 0.17.0 this week. |
the-mikedavis
force-pushed
the
md/khepri-0-17
branch
from
3b09f4c to
1b8eec3
Compare
`locally_known_members/1` and `locally_known_node/1` were replaced with `members/2` and `nodes/2` with `favor` set to `low_latency` - this matches the interface for queries in Khepri.
All callers of `khepri_adv` and `khepri_tx_adv` need updates to handle the now consistent return type of `khepri:node_props_map()` in Khepri 0.17. We don't need any compatibility code to handle "either the old return type or the new return type" because the translation is done entirely in the "client side" code in Khepri - meaning that the return value from the Ra server is the same but it is translated differently by the functions in `khepri_adv` and `khepri_tx_adv`.
If the tree node to delete does not exist, the node props map is empty.
the-mikedavis
force-pushed
the
md/khepri-0-17
branch
from
1b8eec3 to
f2f37d7
Compare
| VersionedPath = khepri_path:combine_with_conditions( | ||
| Path, [#if_payload_version{version = Vsn}]), |
There was a problem hiding this comment.
That’s a good idea to use the payload version here, given the read is outside of the transaction!
But now, I wonder if we need the transaction at all :-)
There was a problem hiding this comment.
I think the transaction would only be necessary for the sake of performance - it's faster to send the one transaction command than many small delete commands (since Ra handles them in serial). We might be able to make it work with async commands though, or a batch API.
The hope with some of the changes in 0.17 is to remove the transaction for regular queue deletion too (rather than just the transient ones here) since that will save resources + be faster
| case {Path, Props} of | ||
| {?RABBITMQ_KHEPRI_EXCHANGE_PATH(VHostName, _), | ||
| #{data := X}} -> |
There was a problem hiding this comment.
Mostly a note to myself: I wonder if ?RABBITMQ_KHEPRI_EXCHANGE_PATH() can be use in the function clause directly instead of having a case.
There was a problem hiding this comment.
I was hopeful we could do that but we would need https://github.com/erlang/eep/blob/master/eeps/eep-0055.md to be implemented - we would want to pin bindings like ^VHostName. Without EEP55 I believe we can't do that, it would be a compile error to re-use the binding if I remember correctly
|
The upgrade to RA 2.16 in the broker seems to cause a flake (#13172) when the stream plugin uses a consistent read to check if some nodes are in maintenance node. Feel free to ping me when you think this PR is ready, I can run the stream plugin test suite against it to make sure the flake is gone. |
This is not ready to be merged yet, Khepri 0.17.0 hasn't yet been released. (And we want to make more changes before then anyways.)
This PR handles the breaking changes in Khepri 0.17.0.