domainOverride means different things for Eureka and Consul

[sleberknight]

We have domainOverride in both the EurekaConfig and ConsulConfig classes. However, it means different things when using Eureka vs. Consul. For Eureka, it means that the URLs of the Eureka services will be changed to include the domain override value, e.g. eureka1.acme.com gets changed to eureka1.dev.acme.com assuming domain override is set to dev.acme.com. Whereas, in Consul it means that we change the domain of registered service instances, e.g. assuming the same domain override value, a service instance would be registered with host name (service address) service-1.dev.acme.com instead of service-1.acme.com.

This is confusing at best. What do we actually need in terms of the domain override, assuming we even need it anymore? And if we do need it, how should it work in both Eureka and Consul? Or, do we need it in Eureka but not Consul, or vice-versa?

[sleberknight]

It turns out we do need the domainOverride for Eureka in the way it is implemented, i.e. to change the domain of the Eureka servers, for historical reasons. Specifically, this need was caused by some rather exotic network configuration in a few special cases, in which some very custom services had to use a different domain. As we transition services from legacy hardware to "the cloud", this won't be needed anymore, and plus we're migrating away from Eureka and to Consul.

When this library was first implemented, we mistakenly added the domain override functionality to the Consul registration, and gave it a completely different behavior. I don't remember why we decided to do this, since this functionality is not needed at all for Consul. So, all related domainOverride functionality can be removed from the Consul registration code. However, since this will change a public API, it necessitates a major version bump from 1.x to 2.x.