THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
Public Interfaces
We shall add a two broker side metrics to track times of successful security store reloadings reloads for success and failure as:
MBean:kafka.server:type=BrokerMetricsBrokerConfigMetrics,name=NumSecurityStoreReloadSuccessPerSec{Success|Failed}SecurityStoreReloadPerSec,store_type=([-.\w]+)
where the current supported store types are: key_store|trust_store.
...
Once the editing for the security store file was done, user should expect the above metric to reflect the reloading of security store instantly. We would also add INFO level message to indicate a reloading event has been triggered, with the reload results following as either success or failure. . If the result is a failure, we would increment the failed metrics and log the reason in ERROR.
When the file watch does not work for unknown reason, user could still try to change the store path in an explicit AlterConfig call in the worst case.
Compatibility, Deprecation, and Migration Plan
...
We have proposed to use a new RPC which gets sent to the target broker directly. The solution involves a couple of compatibility related concerns, such as the following matrix suggests:
| Broker Version | Client Version | Admin API | Expected Behavior |
|---|---|---|---|
| old | new | alterConfig | work with a warning log |
| old | new | storeReload | work with the underlying request translating to AlterConfigRequest |
| new | new | alterConfig | Not work, must use storeReload API |
| new | new | storeReload | work |
| new | old | alterConfig | work, with active controller sending a storeReload request to the target broker |
| old | old | alterConfig | N/A |
...