New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RPC Advertise Address not Advertisable if -bind 0.0.0.0 #186
Comments
I encounter the same pb : bind on 0.0.0.0 is working, but there is a problem with advertise address... only one can be used. In consul, i never encounter this problem... maybe it's implicit... but in nomad you have to specify it. Here is a part of my config :
I have asked in the google gorup about a way to specify a dynamic var like $(hostname -i). |
Ah, so in Consul I think this worked because we had a function that would scan for a private IP address, and automatically use that. There were a number of different opinions surrounding that option, and although in most cases it made things easier to start, it was intentionally left out so that it would always be clear which address we were binding and advertising. It just gets ambiguous if there are multiple interfaces at play. I'm marking this as a thinking ticket, because the UX can probably be improved. Thanks for reporting. |
Maybe, in the case the specific IP address of the server isn't known in advance, its advertise addresses could be derived from a given subnet. Something in the likes of:
I already have a patch somewhere that would look for the first interface to have an IP on the given subnet and use it for advertising, if it is deemed interesting. |
+1 to the subnet idea, or something similar to avoid having to know the IP up front |
@apognu That would be welcome! |
Give me a few hours, I'll submit a PR. |
I'd like to add another thing here, this should behave like consul does, so -bind=:: should work. (Bind to any ipv4 or ipv6 ip address available) as well as the commandline option -advertise= In our consul environment i set all nodes to -bind=:: and then -advertise=<the "real" ip of the node> On all masters i setup a secondary ip-address of 10.255.255.255 on loopback (this is anycasted through our network) so any client anywhere within our network will just "-retry-join=10.255.255.255" and find the closest running master available. serf/raft seems to take care of the rest, the client finds a master and gets the full list of all other masters and then just seems to ignore the -retry-join ip. |
I'm also running into this. Consul's behavior seems to be what most people will like to see, including myself. Also, instead of giving an IP address, I would prefer to specify the network interface. |
Based on the feedback here and feedback that we received in Consul we're considering the following:
Specifying the IP (as is currently supported) is pretty straightforward. If we do interface or CIDR we end up with a lot of messy edge cases.
We end up using similar logic in at least 3 places so this is a good opportunity to factor it out:
I'm not sure this is still supported in Consul 0.6.0. Also, since Nomad does not use serf across the entire cluster (only amongst the server nodes) we may not be able to do things exactly the same way that Consul does them. |
Bit by this issue as well, +1 for binding to named interface. |
Closing this as #941 lets you bind by interface name |
Changes user restore API to blocking (since it was blocking internally).
I'm going to lock this issue because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active issues. |
Getting the following:
This happens only if -bind 0.0.0.0 is set, setting an interface IP clears the error. Occurs whether or not IPv6 is enable. Tested on CentOS 7 and CoreOS Stable (in client only mode)
The text was updated successfully, but these errors were encountered: