Feature/fix travis

[asaladin]

Hi,

I tried to debug the travis-ci issue. On of the problems was with idempotency checks because gpg tests were considered state-changing. The timeout was too small on some builds so I increased it (we can probably safely reduce it slightly).

Now there is a problem with ansible >= 2.0 I tested every pip-installable version between 2.0.0.2 and 2.3.0.0 and they all fail at the wait_for task. However I have found that kafka was correctly listening on the required port (see my debug branch https://github.com/asaladin/ansible-kafka/tree/feature/debug-travis and the travis build https://travis-ci.org/asaladin/ansible-kafka/jobs/230334549#L547, indicating that wait_for fails but netstat shows that the jvm is listening).

My guess it it may be an Ansible bug. I first thought it was due to ansible running with "--connection=local" but I could not reproduce that issue in another repository using netcat as a server.

[jaytaylor]

@asaladin Thanks for digging into this! Your help is much appreciated.

What do you think about invoking nc manually instead of using the ansible function? I'd be curious to know if that produces any different results.

[asaladin]

I made a simple test with netcat. As you can see at https://travis-ci.org/asaladin/ansible-kafka/jobs/230761375, the host value is missing.

This host value {{ healthcheck_address }} should have its value of "{{ server.host_name | default('127.0.0.1')}}". I don't undernstand why thenull value of server.host_name in main.yml is not replaced by 127.0.0.1. To fix that I had to explicitly set server.host_name to localhost by default. I'm not sure about the implications.

[asaladin]

ok so null != undefined that's why

server:
   host_name:
   [...]

in main.yml is not replaced by 127.0.0.1. This does not seem to be a problem for ansible 1.9 but somehow the behavior of wait_for changed with ansible 2.0+

[jaytaylor]

Phenomenal- Thank you @asaladin!!!