-
Notifications
You must be signed in to change notification settings - Fork 593
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cluster/config_manager: fix double apply of configs #13820
base: dev
Are you sure you want to change the base?
Conversation
ducktape was retried in job https://buildkite.com/redpanda/redpanda/builds/37979#018ae223-7888-42d3-9a05-1300186a436f |
ducktape was retried in job https://buildkite.com/redpanda/redpanda/builds/37979#018ae223-788b-4ca8-a781-0d18fd796c7a |
ducktape was retried in job https://buildkite.com/redpanda/redpanda/builds/37979#018ae223-7881-4bd5-9291-da9743a6bfdc |
ducktape was retried in job https://buildkite.com/redpanda/redpanda/builds/37979#018ae223-7885-4745-b692-3c8c3f2b8e92 |
previously, to support validation, the code would call a method and then call it again with a smp::invoke_on_all. this pr preserve this behavior but uses invoke_on_others to eliminate the double-apply on the current shard. to support this, the lambdas needs to be no_except_copy/move, so the parameters are taken by pointer, since they live in the parent scope
5b82e4c
to
e8d6bd3
Compare
ducktape was retried in job https://buildkite.com/redpanda/redpanda/builds/38095#018af071-e6b2-4eab-ab56-942be25f59ad |
ducktape was retried in job https://buildkite.com/redpanda/redpanda/builds/38138#018af273-57f1-4502-bd0f-684480f4b8bb |
ducktape was retried in job https://buildkite.com/redpanda/redpanda/builds/38138#018af273-57e6-4b30-a351-89b2467ba0f8 |
ducktape was retried in job https://buildkite.com/redpanda/redpanda/builds/38138#018af27d-647b-4c53-a47c-45a12e7b7690 |
ducktape was retried in job https://buildkite.com/redpanda/redpanda/builds/38138#018af27d-6472-40ec-98e0-b4b1b25c3e24 |
ducktape was retried in job https://buildkite.com/redpanda/redpanda/builds/38240#018afa53-d51d-461d-9f9c-d487df8aa5d0 |
ducktape was retried in job https://buildkite.com/redpanda/redpanda/builds/38240#018afa62-c855-4ed8-8396-1685e226142a |
note: i've been following admin_sever::patch_cluster_config_handler and there are some issues there as well, seems like a configuration is available in the shard before it has been propagated, and that is in contrast with the purpose of api validation |
ducktape was retried in job https://buildkite.com/redpanda/redpanda/builds/38257#018afb0e-e104-4284-8695-32547bcd473b |
ducktape was retried in job https://buildkite.com/redpanda/redpanda/builds/38257#018afb1c-61f5-40c9-a2b2-db177cb30801 |
Found the manifestation of the alias not persisting after a reboot In this excerpt, after a restart, the node rejoins and applies a snapshot of configs. From the log, delete_retention_ms has the new value, but just after that, another entry has log_retention_ms set to the old value, and since it comes after, it overwrites the value. The name log_retention_ms appears even though the test only applied the old name. This is because when dumping the properties, the new name is used, and somehow, this was merged with a dump where the old names appear (and the old name actually has the new value!) This means that there is a need to normalize these values, and that in the context of partial upgrades + rollback this might result in the original cluster losing some properties, so a test needs to be crafted for this scenario
|
ducktape was retried in job https://buildkite.com/redpanda/redpanda/builds/38464#018b05d8-0db4-443d-a5be-fc8211fb3040 |
ducktape was retried in job https://buildkite.com/redpanda/redpanda/builds/38464#018b05d8-0dad-4426-a6e7-7d46d0323da2 |
ducktape was retried in job https://buildkite.com/redpanda/redpanda/builds/38464#018b05e0-91a6-4dac-b5c5-64ec820d0904 |
@andijcr : Is this PR still valid? What is next here? |
previously, to support validation, the code would call a method and then call it again with a smp::invoke_on_all.
this pr preserve this behavior but uses invoke_on_others to eliminate the double-apply on the current shard.
to support this, the lambdas needs to be no_except_copy/move, so the parameters are taken by pointer, since they live in the parent scope
Fixes #13362
Fixes #13787
Backports Required
Release Notes