kevin-wu24 commented on PR #21053: URL: https://github.com/apache/kafka/pull/21053#issuecomment-3618679837
Thanks for the discussion @ahuang98 @0xffff-zhiyan: > I don't necessarily agree with allowing a user add a bad config - this could become a vulnerability if we don't have a cap on number of configs I think I misunderstood your original comment. I agree that if we ignore the existing config metadata state and only validate what is contained in the `ALTER_CONFIG` request, a given version of kafka's dynamic config will be valid. When going between major versions, the removal from source code of config will not invalidate the existing dynamic config state on the new version of kafka, and allows `ALTER_CONFIG` to complete. This matches how the static `.properties` config is validated by kafka. > My only concern is: Is it really the right approach to let Kafka tolerate configurations that should no longer exist in the metadata? If we ever introduce new logic that handles existing configs in the future, we might have to keep adding code paths that explicitly ignore these existing but invalid configs Dynamic configs that are not known by kafka, just like static configs, shouldn't invalidate the entire config. In this case, they are because `ALTER_CONFIG` will fail. The argument here is that we should not have been validating the existing dynamic config in the first place, since what is a "valid" (dynamic OR static) configuration depends only on the software version of kafka. If I change software versions, fields in my static `.properties` file can go from valid -> unknown by kafka, and loading in those unknown configs into `KafkaConfig` does not throw an exception because they are ignored. We should apply this semantic to the dynamic configuration too. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
