I hope they can move to GUIDs or some other solution soon and facilitate consul's use in "dynamic" (at leat from consul's point of view) IP environment, say inside Docker, etc.
Which option would that be for a server config?
Are you wanting to have a single consul service running for the whole environment (as client and server)? If you're running an HA environment you should really have dedicated master nodes and non-voting clients for service discovery on instances. The member states of consul clusters have an IP and ID, are you saying that the IP could be mixed with a different ID (it could in the cloud, but upon connecting to the leader it would update its registered information).
Are you talking about cleaning up old instances registered in the cluster? Or that there could be a single master node which has a broken network connection to the other master nodes, so sees different cluster status information? In that case, you should be monitoring all your services. Always. There are a lot of tools out there which will clean up and correct voting clusters in those situations. We use Sensu and Kubernetes checks / services for a lot of monitoring and automatic reaction to changes in cluster health.
From the docs:
-advertise - The advertise address is used to change the address that we advertise to other nodes in the cluster. By default, the -bind address is advertised. However, in some cases, there may be a routable address that cannot be bound. This flag enables gossiping a different address to support this. If this address is not routable, the node will be in a constant flapping state as other nodes will treat the non-routability as a failure.
It is waiting for the previous IP, who was the leader, to join... My understanding is that it's not solved?
https://github.com/hashicorp/consul/issues/457
Or maybe I could set the reaping delay from 72h to 0 in that case.