allow multiple CONSUL_BIND_INTERFACE values

[danielmotaleite]

i want to deploy consul agent to several rancher machines, but some different interface names, so i'm unable to create a deploy to run on all hosts because i can only have one CONSUL_BIND_INTERFACE or it can only have one value. To workaround, i have to create multiple configs, each for each machine type and scale then to the number of existent machines, so a manual operation to do when scaling up and down the cluster.

If the CONSUL_BIND_INTERFACE could have several values, like a json list it would be perfect, i could list all the interfaces names and consul would use the first that matched

[dweomer]

@danielmotaleite wrote:

i want to deploy consul agent to several rancher machines, but some different interface names, so i'm unable to create a deploy to run on all hosts because i can only have one CONSUL_BIND_INTERFACE or it can only have one value. To workaround, i have to create multiple configs, each for each machine type and scale then to the number of existent machines, so a manual operation to do when scaling up and down the cluster.

If the CONSUL_BIND_INTERFACE could have several values, like a json list it would be perfect, i could list all the interfaces names and consul would use the first that matched

I have solved this in the past performing one-time configuration-management/introspection of the available interfaces on a machine (early at provisioning or late at boot) and enlisting the appropriate interface in a bridge, consul0, and having Consul listen there.

The other type of solution that has worked well for me is implementing an entry-point shim for Consul that performs the introspection and drops the appropriate config files in the --config-dir to be picked up (remember, these are lexically sorted and last value in at a config leaf node wins) and then exec the supplied entry-point script.

[danielmotaleite]

I was going the entry-point shim, but i workaround instead by creating several configs to deploy on all instances of the same type. So if i use 3 types of instances, i created 3 "run on very machine" stacks, limiting each stack to their own instance type.

It works, but it still feal dirty, if we add a new instance type, we need to make sure it have a new stack.
IMHO, CONSUL_BIND_INTERFACE should accept a list of interfaces, or as alternative, a script to find it