tests: use /var/tmp instead of /tmp to avoid travis failures

[blackboxsw]

Proposed Commit Message

/tmp is not guaranteed to be stable during early system boot.
It is better to use /var/tmp as /tmp may be remounted during
early boot and lead to spurrious build failures. This issue is
related to LP: #1707222.

Additional Context

This could have hit my travis build at https://app.travis-ci.com/github/canonical/cloud-init/jobs/548632221#L8762
where the tmpdir didn't exist anymore.

Test Steps

PR Integration tests should cover this, could introduce an assert 0 intentionally locally to make sure it creates the right subdir

Checklist:

• My code follows the process laid out in the documentation
• I have updated or added any unit tests accordingly
• I have updated or added any documentation accordingly

[TheRealFalcon]

I think the root of your failure was fixed in:
#1110

By default, if a test failed, we'll collect-logs and transfer it to the machine running the tests. LOCAL_LOG_PATH here refers to where to transfer files on the machine currently running tests (generally your local machine). It can be overridden in user_settings.py. I default it to /tmp as these files could build up and take a lot of space, and /tmp is just generally more common than /var/tmp'. The location here shouldn't be affected by any early boot startup races.

If you have strong opinions I'm open to changing it, but I prefer /tmp here.

[blackboxsw]

I think the root of your failure was fixed in: #1110

By default, if a test failed, we'll collect-logs and transfer it to the machine running the tests. LOCAL_LOG_PATH here refers to where to transfer files on the machine currently running tests (generally your local machine). It can be overridden in user_settings.py. I default it to /tmp as these files could build up and take a lot of space, and /tmp is just generally more common than /var/tmp'. The location here shouldn't be affected by any early boot startup races.

If you have strong opinions I'm open to changing it, but I prefer /tmp here.

Defaulting to /tmp makes sense generally and I think you are right that the related PR actually fixed this issue. What I was wondering here is that our CI runs are hosted on a clean travis build container that is just launched for this "Integration Tests" test stage and whether we'd get in early enough to kick off tox -e integration-tests and attempt to write a failure to the travis nodes /tmp which ends up getting clean mounted. Looking in detail at our .travis.yml though, there is soo much we are doing before running the integration tests (like installing deb dependencies and running a full sbuild) that there is really no way we get in there early enough for this to be a problem. If it does show up for us in travis runs, we can change it specifically for .travis.yml with

diff --git a/.travis.yml b/.travis.yml
index 1582e829..5482209f 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -121,7 +121,7 @@ matrix:
             # Use sudo to get a new shell where we're in the sbuild group
             - sudo -E su $USER -c 'sbuild --nolog --no-run-lintian --verbose --dist=xenial cloud-init_*.dsc'
             - ssh-keygen -P "" -q -f ~/.ssh/id_rsa
-            - sg lxd -c 'CLOUD_INIT_CLOUD_INIT_SOURCE="$(ls *.deb)" tox -e integration-tests-ci'
+            - sg lxd -c 'CLOUD_INIT_LOCAL_LOG_PATH="/var/tmp/cloud_init_test_logs" CLOUD_INIT_CLOUD_INIT_SOURCE="$(ls *.deb)" tox -e integration-tests-ci'
         - python: 3.5
           env:
               TOXENV=xenial