... | ... | @@ -22,9 +22,7 @@ The TLS work will continue in the upcoming releases. |
|
|
|
|
|
We do encourage people to test this and report their experience. We're particularly interested in which OS, OpenSSL or Botan, and Boost versions were used.
|
|
|
|
|
|
**Database connection recovery rework**. A new parameter "on-fail" now controls what to do on
|
|
|
database connection loss. It has three possible values: "stop-retry-exit" (stop DHCP service, attempt to reconnect and terminate if unable to reconnect), "serve-retry-exit" (continue serving DHCP traffic, attempt to reconnect and terminate if unable to reconnect), and "serve-retry-continue" (continue serving DHCP traffic, try to reconnect, and continue serving even if reconnection fails) which govern if the DHCP service should be disabled and if Kea should shut
|
|
|
down or continue retrying after all the configured tries. This is particularly useful for forensic logging and config backend services. Depending on your specific deployment, you may prefer one strategy or another #1621.
|
|
|
**Database connection recovery rework**. A new parameter "on-fail" now controls what to do on database connection loss. It has three possible values which govern if the DHCP service should be disabled and if Kea should shutdown or continue DHCP service after all the configured tries were exhausted: "stop-retry-exit" (stop DHCP service, attempt to reconnect and terminate if unable to reconnect), "serve-retry-exit" (continue serving DHCP traffic, attempt to reconnect and terminate if unable to reconnect), and "serve-retry-continue" (continue serving DHCP traffic, try to reconnect, and continue serving even if reconnection fails). This is particularly useful for forensic logging and config backend services. Depending on your specific deployment, you may prefer one strategy or another #1621.
|
|
|
|
|
|
**Multi-threaded HA work**. Kea 1.8 introduced multi-threaded support for DHCP packet processing, which offers substantial performance gains. Unfortunately, if used with HA, the current implementation makes the lease updates sequential, effectively eliminating the benefits of multi-threading. This limitation requires substantial rework of how HA connections are established. In this milestone we made substantial progress towards solving this bottleneck. The MT-HA design has been proposed and reviewed #1315. Also, the first major element of the solution (a multi-threaded HTTP listener) has been reviewed and merged #1748. The HA-MT solution is not functional yet, but definitely completed the experiments and planning phase and moved onto the implementation phase. This work will continue in the next releases.
|
|
|
|
... | ... | |