Fix to make it possible to read file on a remote node

[userlocalhost]

When I execute stackstorm.yml playbook to build StackStorm environment from another (management) node, the following task is failed.

TASK [bwc : Read bwc_license_hash from file if it exits] ***********************
 [WARNING]: Unable to find '/etc/packagecloud/bwc_license_hash.txt' in expected paths.

fatal: [192.168.100.14]: FAILED! => {"failed": true, "msg": "An unhandled exception occurred while running the lookup plugin 'file'. Error was a <class 'ansible.errors.AnsibleError'>, original message: could not locate file in lookup: /etc/packagecloud/bwc_license_hash.txt"}
        to retry, use: --limit @/home/ubuntu/ansible-st2/stackstorm.retry

The task of Read bwc_license_hash from file if it exits failed to read the bwc_license_hash_file. Because the when statement checks a condition on the target (may be remote) node, but the Lookups plugin accesses data only on the local node (*1).
(*1) http://docs.ansible.com/ansible/playbooks_lookups.html

This patch avoid this problem by reading the file on the target node and setting it to the variable.

Thank you.

[userlocalhost]

I think the reason of a failure in the TravisCI is caused of the configuration for hubot.
Could you please tell me the way to solve it, @armab?

[arm4b]

@userlocalhost You're right, good catch!

We totally missed that lookup is executed on Ansible host, which means it will succeed in ansible-pull mode (our default environemnt), but will fail in ansible-push mode (cc @lakshmi-kannan).

Thanks for PR, will review it shortly.

[arm4b]

@userlocalhost The change looks good 👍
Thanks for the fix!

[arm4b]

Yeah, CI is failing on unrelated to this PR st2chatops.

@humblearner any ideas how we can fix/improve st2chatops? It's failing not every time, but still pretty frequently, making the build unstable.

TASK [st2smoketests : Verify st2chatops using bin/hubot] ***********************

       task path: /tmp/kitchen/roles/st2smoketests/tasks/st2chatops_smoketests.yml:50

       fatal: [localhost]: FAILED! => {"changed": false, "cmd": ["timeout", "10", "bin/hubot"], "delta": "0:00:10.040144", "end": "2017-04-18 08:00:51.138462", "failed": true, "failed_when_result": true, "rc": 124, "start": "2017-04-18 08:00:41.098318", "stderr": "", "stdout": "[Tue Apr 18 2017 08:00:42 GMT+0000 (UTC)] DEBUG Loading adapter slack\n[Tue Apr 18 2017 08:00:42 GMT+0000 (UTC)] ERROR No services token provided to Hubot\n[Tue Apr 18 2017 08:00:42 GMT+0000 (UTC)] ERROR Error: listen EADDRINUSE 0.0.0.0:8081\n  at Object.exports._errnoException (util.js:907:11)\n  at exports._exceptionWithHostPort (util.js:930:20)\n  at Server._listen2 (net.js:1253:14)\n  at listen (net.js:1289:10)\n  at net.js:1398:9\n  at nextTickCallbackWith3Args (node.js:522:9)\n  at process._tickCallback (node.js:428:17)", "stdout_lines": ["[Tue Apr 18 2017 08:00:42 GMT+0000 (UTC)] DEBUG Loading adapter slack", "[Tue Apr 18 2017 08:00:42 GMT+0000 (UTC)] ERROR No services token provided to Hubot", "[Tue Apr 18 2017 08:00:42 GMT+0000 (UTC)] ERROR Error: listen EADDRINUSE 0.0.0.0:8081", "  at Object.exports._errnoException (util.js:907:11)", "  at exports._exceptionWithHostPort (util.js:930:20)", "  at Server._listen2 (net.js:1253:14)", "  at listen (net.js:1289:10)", "  at net.js:1398:9", "  at nextTickCallbackWith3Args (node.js:522:9)", "  at process._tickCallback (node.js:428:17)"], "warnings": []}

[humblearner]

@armab: I have increased the timeout to 25 for bin/hubot. I'll keep an eye if it still fails.

[humblearner]

Thanks for the PR @userlocalhost 👍. Just merge the latest from master. That should take care of the CI 🤞

[arm4b]

Thanks @humblearner for checking. I've synced this PR with master.

The failure is still there.
After looking further, the error is caused by private env variables defined in our Travis settings: HUBOT_SLACK_TOKEN and BWC_LICENSE not available to forked builds.

https://docs.travis-ci.com/user/environment-variables/#Defining-Variables-in-Repository-Settings

Similarly, we do not provide these values to untrusted builds, triggered by pull requests from another repository.

[arm4b]

Considering master build is OK and the change in this PR is clear improvement, - I'll go ahead and merge it.

But not sure how to proceed this the right way in future, - because we can't turn down CI for contribution PRs.

[arm4b]

Yeah, master is green after merging this PR.
Thanks @userlocalhost for contribution!

Talking about forked CI failures, - created new Issue: #141 for that.

[arm4b]

Just a follow-up, CI for forked PRs should work well via
#143 and #144