Add rescue option for OS upgrade failure + test via docker build #121
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
nickjj
requested changes
Sep 17, 2022
tasks/main.yml
Outdated
| rescue: | ||
| - name: Handle upgrade case | ||
| ansible.builtin.file: | ||
| path: /usr/local/lib/docker/virtualenv |
There was a problem hiding this comment.
We should replace this hard coded path with: "{{ docker__pip_virtualenv }}"
tasks/main.yml
Outdated
| - name: Handle upgrade case | ||
| ansible.builtin.file: | ||
| path: /usr/local/lib/docker/virtualenv | ||
| state: absent |
tasks/main.yml
Outdated
| ansible.builtin.file: | ||
| path: /usr/local/lib/docker/virtualenv | ||
| state: absent | ||
| - include_tasks: main.yml |
There was a problem hiding this comment.
Is this going to re-run everything? I haven't used this pattern in Ansible yet.
Ideally I wonder if we can detect an upgrade occurred before the task runs so we can delete the file before this task runs.
Then we wouldn't need to rescue anything and the whole feature becomes maybe a single task to detect if it an upgrade happened and delete the file, else it does nothing.
There was a problem hiding this comment.
You're right, it did re-run everything. Just pushed a new version that is able to detect in advance and not do this.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A first pass at trying to solve: #117
I was able to reproduce the failure mode reliably with the added Dockerfile.
You can try it out by running:
docker build -f tests/Dockerifle .from the main folder of the repo.The dockerfile uses multistage builds. In the first stage, it uses Ubuntu20.04, applies the playbook. Then in the next stage, it starts from Ubuntu22.04, and then copies the virtualenv from the previous stage, as if an upgrade had been done without cleaning this up. It then tries to run the playbook again and then fails.
I converted the failing task to a
blockandrescue, and then when the rescue happens, it clobbers the virtual env and then just tries to apply the playbook again. This appears to work succesfully.The only hangup I had, was trying to apply the playbook during a docker build - there is no systemd and docker can't run in a service while building, so I just added a couple of new default variables that toggle off the restart handlers.
Might not be the best way to do it, but open to suggestions!