We currently have two issues with venvs:
- if you update your venv on the repo server, it is not possible for
that updated venv to land on the service's container as the get_url
task always skips if the file exists (even if the file is different)
- if you have an updated venv on the repo server and forcefully delete
the cached venv tarball on the service's container, the new tarball
will get unarchived over top of the existing venv
This commit does the following:
- updates repo_build/tasks/repo_venv_build.yml to create checksum files
of each venv tarball
- gets the checksum of the /var/cache tarball and downloads checksum
file from repo server
- updates "Attempt venv download" to only download the venv if the
cache doesn't exist or if the local and remote checksums differ
- adds a "force: true" to "Attempt venv download" task so that the venv
tarball will get re-downloaded when the when condition is true (this
is necessary otherwise the download will get skipped since the
destination already exists)
- adds a new task "Remove existing venv" so we can first remove the
venv before we unarchive the potentially new venv from the repo
server
- updates "Create horizon venv dir" and "Unarchive pre-built venv"
tasks to only proceed if "horizon_get_venv | changed", which
prevents these tasks from running when they the venv tarball hasn't
changed
NOTE: The reason why we compare local and remote checksum is to avoid
unnecessarily downloading the venv when the checksums are in fact
the same. On small deploys this is more or less a non-issue but
if a deploy w/ thousands of compute nodes re-runs playbooks we
want to limit the venv downloads when it's unnecessary.
Assuming this logic is correct, this review can be updated so that all
similar roles can be updated accordingly.
Change-Id: I41c3576b69d73611a38024f0bc95eeac47787e25
9db6d42f5c