box: apply dynamic cfg even if option value is unchanged #8552
Conversation
|
Don't do this, It's breaking behavior. |
What does it break? All tests pass. The replication configuration callback won't restart replication if it's up and running thanks to commit 5994892. See also #8551 (comment). |
|
Even if it doesn't break things it sets the new mechanics and requires extra attention from callback authors to keep the old behavior. I have a proposal: #8551 (comment). |
|
what exactly can be broken? |
Discussed in issue. If no active replication is restarted in case when nothing changed, then everything is ok. |
If a configuration option value passed to `box.cfg` is the same as the
old one, the option handler isn't called. As a result, one can't restart
the server IPROTO connection or replication by passing the same URI to
`box.cfg`. This is inconvenient, for example:
- To update an SSL key file without renaming it, one has to first pass
an empty URI to `box.cfg.listen` and then reset it back.
- To restart broken replication after fixing it manually (e.g. deleting
a conflicting record on the replica), one has to first set
`box.cfg.replication` to `{}` and then set it back instead of just
calling `box.cfg{replication = box.cfg.replication}`.
There's no reason to skip an option update if the value is unchanged.
It should be up to the option configuration callback.
The only callback that may actually fail on an attempt to set the same
value is `box.cfg.memtx_memory`. This happens because the value is
rounded up to a multiple of the quota unit size so we just need to fix
the check accordingly.
Note that the `box.cfg.replication` configuration callback won't restart
replication if it's up and running even if the URI list is rearranged
thanks to commit 5994892 ("replication: fix replica disconnect upon
reconfiguration"). This commit doesn't break this behavior - it just
removes the `load_cfg.lua` code that would skip option update if the old
and new option values are equal in Lua.
Needed for tarantool/tarantool-ee#432
Closes tarantool#8551
NO_DOC=bug fix; this behavior isn't described anywhere in the docs
locker
force-pushed
the
box-cfg-reload-fix
branch
from
09a726d
to
8b4b088
Compare
|
The client has a right to expect that if the network is OK and the hardware is running fine its queries will not fail. There is a whole class of applications for which it is good enough. Now you're saying you'll be dropping connections for no reason whatsoever, just because somebody reset an unrelated parameter. A lot of applications are not idempotent. With interactive transactions it's even worse. |
I didn't say that. No active connections would be dropped on reconfiguration after this change, because neither Still, after this change reconfiguration of |
If a configuration option value passed to
box.cfgis the same as the old one, the option handler isn't called. As a result, one can't restart the server IPROTO connection or replication by passing the same URI tobox.cfg. This is inconvenient, for example:box.cfg.listenand then reset it back.box.cfg.replicationto{}and then set it back instead of just callingbox.cfg{replication = box.cfg.replication}.There's no reason to skip an option update if the value is unchanged. It should be up to the option configuration callback.
The only callback that may actually fail on an attempt to set the same value is
box.cfg.memtx_memory. This happens because the value is rounded up to a multiple of the quota unit size so we just need to fix the check accordingly.Note that the
box.cfg.replicationconfiguration callback won't restart replication if it's up and running even if the URI list is rearranged thanks to commit 5994892 ("replication: fix replica disconnect upon reconfiguration"). This commit doesn't break this behavior - it just removes theload_cfg.luacode that would skip option update if the old and new option values are equal in Lua.Needed for tarantool/tarantool-ee#432
Closes #8551