Removed Kubernetes self contact points hack #433
Conversation
Fixes akka#424. Issue akka#238 introduced a hack that meant that cluster bootstrap used the pod host name when the kubernetes configuration was present, rather than the IP address, since Kubernetes discovery returned host names rather than IP addresses to work with Istio. That hack was made redundant however by akka#242, which introduced matching by either hostname, or IP address, so it didn't matter if the self host name was an IP address or hostname. However, the hack wasn't removed and stayed there, benign, until akka#415 changed the way namespace configuration is consumed. At that point, the hack was still benign, but resulted in some confusing log messages. This removes the hack.
|
That'd be great. From what I understand, Istio communication should work because the Kubernetes API discovery returns the pod host name in the |
|
There was basically two ways to solve the problem, one was to return both the IP address and the host name from the self contact points (that's what the hack was) and match against either, the other was to return both the IP address and the host name from the discovery API (that's what #242 did) and match against either. Both were done, but only one was needed. |
|
I'm afraid I won't get to adding an Istio test in the near future, so this is OK to merge if you're confident the hack is no longer necessary. |
|
Let's merge and we can look into it again if it's reported as a problem with Istio (so far it hasn't been top priority for us to look into Istio) |
Fixes #424.
Issue #238 introduced a hack that meant that cluster bootstrap used the pod host name when the kubernetes configuration was present, rather than the IP address, since Kubernetes discovery returned host names rather than IP addresses to work with Istio. That hack was made redundant however by #242, which introduced matching by either hostname, or IP address, so it didn't matter if the self host name was an IP address or hostname. However, the hack wasn't removed and stayed there, benign, until #415 changed the way namespace configuration is consumed. At that point, the hack was still benign, but resulted in some confusing log messages. This removes the hack.