-
Notifications
You must be signed in to change notification settings - Fork 50
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
config: separately configure broker bind/config URIs #2572
Comments
Thanks @garlick for writing this up. hosts = [
[ "fluke2", "tcp://eno1:8020", "tcp://efluke2:8020" ],
[ "fluke3", "tcp://eno1:8020", "tcp://efluke3:8020" ],
] My only nit with this example is that it isn't obvious which uri is the bind and which is the connect from the file. My suggestion would be: hosts = [
{ hostname = "fluke2", bind = "tcp://eno1:8020", connect = "tcp://efluke2:8020" },
{ hostname = "fluke3", bind = "tcp://eno1:8020", connect = "tcp://efluke3:8020" },
] This is more verbose with lots of duplication, but it's more self-documenting as well. |
And as @garlick suggested above, the config could have some defaults for "missing" values:
|
Yeah, maybe it's a good idea to use a table for the long form entries, particularly if we want both URI's to be optional. I'm assuming we could support both table entries and bare string (just host) entries in combination?. Maybe we could support a simple hostlist form consisting of a hostname with embedded idset? So e.g. port = 8020
default_bind = "tcp://eno1:%P"
default_connect = "tcp://e%h:%P"
hosts = [
{ hostname = "fluke[2-4]", bind = "tcp://eno3:%P" },
"fluke[5-128]",
] |
Currently the "config file" broker bootstrap method looks for a rank-ordered array of zeromq endpoints:
A broker finds itself in this list by searching through the tbon-endpoints array until it finds an IP address that matches a local interface. It sets its rank to the array index, and calls
zmq_bind()
on this URI.A broker finds its TBON parent in the list by computing its parent rank from its rank and the k-ary tree branching factor, and and looking up the URI by index. It then calls
zmq_connect()
on this URI.The form of this URI is limited by what is acceptable to both
zmq_bind()
andzmq_connect()
. For example, hostnames are acceptable tozmq_connect()
but only IPv4 addresses are acceptable tozmq_bind()
. See http://api.zeromq.org/master:zmq-tcpA more expressive form could be to allow an array entry to be a (hostname, bind_uri, connect_uri) tuple rather than single URI's, e.g.
The hostname could be matched directly against
gethostname()
rather than requiring the more complex (and non portable?)getifaddrs()
for the interface match.A possible (optional) abbreviated form where the bind and connect URI's can be derived from the hostname or or are fixed could be something like:
The text was updated successfully, but these errors were encountered: