add support for for reconfiguration of ssl properties for metrics reporter #2206
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Expected Behavior
To clear up producer failure like
Running
kafka-configs.sh
script with alter command should update the ssl properties for the metrics reporter producer.Actual Behavior
Nothing happens and the producer keeps on failing with ssl handshake errors.
Steps to Reproduce
Known Workarounds
Restart the broker to pick up any new changes.
Additional evidence
logs
Categorization
This PR resolves #1148
some clarification on the changes
cruise.control.metrics.reporter.force.reconfigure=1728690883
is addedEven if support is added to cruise control to reload the configuration, the reload mechanism in kafka doesn't reload in place configurations (aka the key and value are the same as the current configuration)
the listener update flow only considers listener.name.whatever properties and doesn't apply anything else; https://github.com/apache/kafka/blob/2.6.1/core/src/main/scala/kafka/server/DynamicBrokerConfig.scala#L312-L331 and will always update even if there is no config difference
thus, configuration can't be forced the update without the value of the config actually changing, too, so in place configuration wouldn't trigger the reconfigure since the location/filename or password didn't change, but that doesn't mean the contents of the truststore or keystore didn't change
this logic is gated by
updatedConfigs
logic here: https://github.com/apache/kafka/blob/67df232bec296eaf76650b01088049c11aa2a168/core/src/main/scala/kafka/server/DynamicBrokerConfig.scala#L531and doesn't run the update flow unless there is a config difference, therefore adding a new field that can change without consequences to trigged the reconfiguration to run if an in place change is done.
I don't know too much about configuration for sasl (or testing it), so I only implemented changes for ssl. But I don't see why sasl couldn't be added on top of these changes.
Went back and forth on this, I suppose can add something since closing and re-creating the producer can cause issues in the reporting thread (aka producer closed exception) but everything is wrapped in a try/catch so it should just continue on and try again. Up to you guys what how you feel about this.
kafka-configs.sh
alter cmd, thelistener.name.etc
is also requiredAll sensitive broker config entries must be specified for --alter, missing entries
I don't think there is a way around this.
or the other way around too.
so this change could break users alter command, now needing to include cruise control ssl properties now too; https://github.com/apache/kafka/blob/dd71437de7675d92ad3e4ed01ac3ee11bf5da99d/core/src/main/scala/kafka/admin/ConfigCommand.scala#L343-L346