Fix for deploying Cassandra 2.2 on an overlay network.

[gmouchakis]

When deploying Cassandra 2.2 on an overlay network without defining CASSANDRA_LISTEN_ADDRESS deploy fails with error:

Exception (org.apache.cassandra.exceptions.ConfigurationException) encountered during startup: Unknown listen_address '10.10.0.26 172.18.0.16'
Unknown listen_address '10.10.0.26 172.18.0.16'
ERROR 15:09:21 Exception encountered during startup: Unknown listen_address '10.10.0.26 172.18.0.16'

This happens because the default behavior in docker-entrypoint.sh is:
CASSANDRA_LISTEN_ADDRESS="$(hostname --ip-address)"

On an overlay network 'hostname --ip-address' will return two space-separated IPs, e.g. '10.10.0.26 172.18.0.16'

To fix this we have to keep only the first IP so the above is changed to
CASSANDRA_LISTEN_ADDRESS="$(hostname --ip-address | cut -d " " -f1)"

This is a fix for issue #56.

[gmouchakis]

Travis CI build failed on an APT network error. It builds successfully.

[tianon]

I'd really like to answer the question I outlined in #56 (comment):

Does this mean that 3.x handles multiple values for these IP address keys without problems? For 2.x, should we parse the hostname --ip-address output to scrape off just the first value, or simply document this quirk?

What is 3.x doing differently with multiple values? Is it simply using all of them? Taking the first? Not even working as intended? The fact that it doesn't throw an error in 3.x makes me wonder if it's actually doing something sane there, or whether it's simply changed the way they read the value such that it's silently dropping part of it.

[rjohnson3]

@tianon To answer your question, 3.x IS broken. It seems to work by accident when it is the only node. But if you try to setup a cluster, no other node can communicate to it because the listen and broadcast addresses are incorrect due to the two ip addresses

[kopachevsky]

I do need to have this fix merged, but what if we'll have 2 overlay network, does it make sense to take first IP every time?

[yosifkit]

@kopachevsky, yeah that is the kind of thing that makes me hesitant on this change, but is there a better way? Maybe we take a sed pattern match or cidr like environment value to determine which address to choose?

[tianon]

I agree -- just taking the "first" feels somewhat wrong to me as well, especially since the order of the two isn't necessarily deterministic IIRC.

[gmouchakis]

This fix is only for cases where the user does not set a listen address IP and expects the default behaviour ('auto' in docker-entrypoint.sh). At the moment this fails on overlay networks because of the two IPs. If the user wants to configure Cassandra with multiple network interfaces, in multiple overlay networks and other special cases then it is up to the user to do the proper configuration and not use the default.

I think that the first IP should be used by default because when deploying on overlay and Swarm most of the times you want to use the first.

[kopachevsky]

@gmouchakis I can't agree with "then it is up the the user to do the proper configuration" I don't sure this is possible on most common cases, as I know only thing user can do is to explicitly set ip for LISTEN_ADDRESS. With swarm using static ip's I'll lose all flexibility of dynamic scaling in and out. Maybe there is another way co fix problem with configuration from user side?

[kopachevsky]

@yosifkit that might be crazy idea, for my would work if I'll pass network CIDR as env param, and ip that fits this CIDR will be chosen. I know this is lots of scripting, but this would give more predictable behavior for listen address lookup.

[gmouchakis]

@kopachevsky you can scale out by setting the IP of the seed node (CASSANDRA_SEEDS variable) when adding new nodes. You can also get the IP of the seed node with docker inspect in order to avoid static IPs.

[tianon]

I think this was fixed by #146 and #151. 👍