in setup.yml, adding cleanup tasks for any previous incomplete deploys #209
Conversation
…", which is a pretty standard command.
|
👎 our rollback role deletes rolled back deployments by default so if they are not deleted, this is because the user configured it to do so (https://github.com/ansistrano/rollback/blob/master/tasks/cleanup.yml) |
|
Right, but that's not the point of my pull request. My pull request cleans up previously abandoned incomplete deploys (in the case that a dev forgot to run rollback or whatever), so that if a dev subsequently deploys more releases, the incomplete deploy doesn't become present in the releases directory. If the incomplete deploy were accidentally rolled back to, it would break a site. It's a protection for devs. |
|
Still not convinced, unless you can provide a good use case If you need to clean a server mess, this is what the before setup hook can be used for |
|
Here's the use case I tested. I started a deploy, then hit Ctrl-C after the new release directory was created, but before the symlink switch to mimic a failed deploy. So it created a new release in an inconsistent state. If it had been a genuine failure, the dev who would be deploying wouldn't know necessarily how inconsistent the site code would be. Had the deploy created a new release directory or had it not? The rollback mechanism of Ansistrano executes differently depending on those 2 scenarios. Ansistrano would either delete the incomplete release, or it would fully rollback to a previous release. It's inconsistent, and the dev wouldn't necessarily know which thing would happen, so it makes rollbacks potentially dangerous. My code helps to protect against that. The true solution is to have Ansible exception handling in the playbooks and to handle an Ansible exception with a rollback, but until Ansible supports that kind of thing, I think doing a cleanup step is a good way to go. Yes, I currently utilize the setup hook for this, but it seemed generally useful enough that I thought it would be beneficial in Ansistrano proper. |
|
Yeah I understand, but if you do ctrl-c, you need to fix the mess deploying your current stable, not Ansistrano. It is the same if you are going to install sth and you ctrl-c half eay through Sorry but we want to keep it simple and I don't think this is the way to go. When we deprecate Ansible 1.9 we may add some recovery steps in order to delete these situations |
|
Ctrl-C was only to simulate a failure, and I did it in the worst possible spot in the deploy process to make sure what I was writing would be reliable. Obviously a real failure would happen in various spots. What kind of recovery steps are you thinking about? Would they be automatic? If what you are thinking about is more reliable than what I wrote, I might like to implement your solution for my installation of Ansistrano. |
|
Well, as of 2.0 there is this: http://docs.ansible.com/ansible/playbooks_blocks.html So, the idea would be to do sth in main like block: everything until the symlink changes and block: everything after symlink |
|
I didn't know blocks could also have a rescue. I agree that what you
outlined is a better approach. How long until we can see it in Ansistrano?
:)
…On Sun, Feb 26, 2017 at 6:45 AM, Ricard Clau ***@***.***> wrote:
Well, as of 2.0 there is this: http://docs.ansible.com/
ansible/playbooks_blocks.html
So, the idea would be to do sth in main like
block: everything until the symlink changes
rescue: delete half way through deployment (similar to your stuff, but
done in the failed deployment, not subsequently when many things may have
happened to the server)
and
block: everything after symlink
rescue: roll back to previous stable as a broken step may lead to an
inconsistent state
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#209 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAgsoH7LbaE5FsJQJgtyjpRIkK2s8n71ks5rgWXogaJpZM4MKkbi>
.
|
|
Hehe, we just dropped support for 1.8, we have been sending anonymous stats about the ansible versions people are using but we are not analysing them. We have plans to do it soon and depending on the results we may move to minimum Ansible 2.1 (2.0 is so buggy that it´s not worth it) but keeping BC is part of the success of the project and we need to be cautious |
|
Closing as we will cleanly implement this once we deprecate 1.9 |
Hey, I added a check to prevent a situation where an incomplete deploy can be rolled back to. If a deploy is cancelled after code update, but before any further steps, it sits unused on the server potentially incomplete. A dev is able to roll back to this incomplete deploy later by accident. The check I added prevents this situation at the beginning of a deploy by deleting any deploys that are newer than what the "current" symlink points to. Let me know if there are any questions. Thanks!