I am confuse about “retry_join” arguments, I have 3 Consul servers (A,B,C) and 3 Consul clients (D,E,F).
When I config retry_join on Consul server do I need to include Consul client? like “retry_join=[A,B,C,D,E,F]” or just Consul server “retry_join=[A,B,C]”
When I config retry_join on Consul client do I need to include Consul client? like “retry_join=[A,B,C,D,E,F]” or just Consul server “retry_join=[A,B,C]”
-retry-join - Similar to -join but allows retrying a join until it is successful. Once it joins successfully to a member in a list of members it will never attempt to join again. Agents will then solely maintain their membership via gossip. This is useful for cases where you know the address will eventually be available. This option can be specified multiple times to specify multiple agents to join.
@Wolfsrudel What are the best practices with let’s say a cluster of 3 server nodes? What should retry_join normally - by common sense - contain? The IPs of the other two nodes, for example?
What if you wanted to avoid hardcoding to IPs? Would that be possible? Would the gossip protocol be enough for the nodes to find one another if they have the right token/datacenter/ACLs?
It might be possible to come up with a workflow that populates the retry_join addresses based off of data injected into the instance over cloud-init.
For example, you a valid workflow might be using cloud-init’s write_files directive to write a JSON file into /etc/consul.d/retry-join-hosts.json that contains the retry_join directive with the addresses of other servers in your network.
So you think the openstack provider would work even if I don’t actually use openstack?
I did try that at some point and it kept trying to connect to a http server available on 169.254.x.x, which openstack might provide by default, I’m guessing? I’m not sure how you’re supposed to provision that only using cloud-init and making it believe that you use openstack (if that’s what you were thinking about also).