Configuration .Values.tls.proxy.enableTlsWithBroker and .Values.broker.enableForProxyToBroker are conflicting about pulsar-helm-chart HOT 1 OPEN

Good question. .Values.tls.broker.enableForProxyToBroker and .Values.tls.broker.enableForFunctionWorkerToBroker were introduced in #172, but they've never been used. I added them by accident, and I have a PR to remove them here #195. The config for .Values.tls.proxy.enableTlsWithBroker and .Values.tls.function.enableTlsWithBroker are used. .Values.tls.proxy.enableTlsWithBroker is poorly named because it also determines the type of connection to the function worker, too.

Wouldn't it make sense to have .Values.tls.broker.enabled instead?

I considered this design when writing #169, #170, and #172. The primary reason I didn't use it is because I was worried it'd be a bit ambiguous what was being enabled (TLS is currently enabled on the broker via enableTls). However, in revisiting the logic, I am not sure that I agree with it anymore. I think your solution is good, but the ideal solution is probably even simpler. We really have two TLS features: enable TLS on inbound connections to the proxy (and maybe the broker/function worker?) or enable TLS for all component networking. The current chart is too configurable. For example, I don't know of a use case that would require TLS for bookkeeper connections but not for zookeeeper connections.

For more context, I seem to have noticed the logical inversion based on the below comment. For some reason (I don't remember why), I didn't view .Values.tls.broker.enabled as a good alternative to prevent this inversion.

Moving forward, I think we should prepare for a 3.0 release and try to greatly simplify the TLS configuration while making a few breaking changes by ignoring certain configs that make the chart too configurable.

from pulsar-helm-chart.