Drupal 10, the latest version of the open-source digital experience platform with even more features, is here.This has been a long running problem, if you are used to aegir you just "deal with it".
Let's be honest: it's a big cause of some of the AegirHate out there. If you can't cleanly delete things from the system it is very frustrating. It just feels broken.
Scenario #1:
- Site Delete task is triggered, and deletes database, but fails to update status to Success for some reason.
- Since the task failed, User assumes Site Delete didn't work. Hit's "Retry".
- Second run of Site Delete task fails because "Unable to Drop Database".
- Site is permanently stuck in "enabled" mode, even though it's been destroyed. The only recourse is to manually delete the node by visiting node/%/delete or the admin pages.
Solution: In this scenario, the second "Site Delete" task should finish with a warning, because the desired end state (no database) is reached.
Scenario #2:
- Platform Delete task is triggered, and deletes files, but fails to update status to success for some reason.
- Since the task failed, User assumes Site Delete didn't work. Hit's "Retry".
- Second run of Site Delete task fails because "The directory /var/aegir/platforms/drupal does not contain a valid Drupal installation".
- Platform is permanently stuck, in an active state, because you can't delete it or verify it.
This also occurs if one were to manually delete the files from the platform and then run a Delete Platform task.
Solution: In this scenario, the second "Platform Delete" task should finish with a warning, because the desired end state (no files) is reached.
Let's try to find, describe, and fix problems like these.
| Comment | File | Size | Author |
|---|---|---|---|
| #14 | 2666158-dont-backup-missing-site.patch | 2.25 KB | Jon Pugh |
| #7 | Screenshot from 2018-01-31 16-08-44.png | 14.39 KB | Jon Pugh |
| #3 | Screenshot from 2016-02-10 18:55:18.png | 8.09 KB | Jon Pugh |
Comments
Comment #2
ergonlogicFirst off, referring to hatred of the project is simply demotivating, and reminds me of this little diatribe. Let's try to avoid it.
Secondly, neither of the scenarios you describe result in the "desired end state". The reason the delete task failed in the first place presumably still exists. Furthermore, setting the task status to "warning" won't have any effect on the state of the site or platform. So it'd still need to be manually cleaned up.
I think a more productive approach would be to detect and address the types of failures that lead to such scenarios. Also, I've begun work to add "Purge" tasks, that would, to the extent possible, safely automate clean up of such error states: http://cgit.drupalcode.org/hosting_dev/tree/modules/purge/README.md.
Comment #3
Jon PughApologies if my comments were demotivating, my intent was the exact opposite. My hope is that we can be honest about our project's pain points so that we can address them.
An I understand about handling all of these situations better.
So in that spirit... the site deletion one is one that can't be worked around without manually deleting the site node, site alias, etc. You can also get into this state by using a "proper" procedure of using drush provision-delete via CLI, then going into hostmaster and hitting the "delete" button..
It also results in a site that appears "enabled" in the front-end, even if it's been totally destroyed in the back.
Here's a bad delete task... It looks like there is a warning, and there is also an error. Seems like at some point Aegir was ok with the warning, then at some point we added the error.
Happy to help address this when I have some more time next week.
Comment #4
Jon PughAt the very least, we should tell the user why it failed to drop the database and some kind of recourse to take.
Comment #5
Jon PughThe bigger problem with Site Delete failing is that it does not delete the sites/DOMAIN/settings.php file. All other files in the sites folder get deleted.
With this file still there, it blocks you from being able to delete the platform until you SSH in and remove this file, otherwise you get the message "There are still sites on this platform".
So, as a first step, we should figure out how to let Site Delete tasks finish as much as they can (including deleting their sites/DOMAIN folder).
This would at least allow you to continue and delete the platform.
Comment #6
Jon PughAfter many years of this, I finally learned that provision-delete command already has a "force" option.
I also understand now why the code triggers a task failure: it is unable to make a backup.
If I add a "force" option to the hosting_task_form 'parameters' it works in fully deleting a site that failed to install!
We can simply add a variable now: "When deleting sites, fail if a backup cannot be made."
I think we should make this variable TRUE by default.
Comment #7
Jon PughUpdating the title to reflect the solution: If we were able to run with --force, this is no longer an issue.
Solution is a new variable:
Screenshot:
Comment #10
helmo CreditAttribution: helmo at Initfour websolutions for Aegir Cooperative commentedSounds good to have that on /admin/hosting/settings
I added one minor commit, you were checking the variable_get('hosting_delete_force', FALSE) twice.
Comment #12
helmo CreditAttribution: helmo at Initfour websolutions for Aegir Cooperative commentedmerged
Comment #14
Jon PughReopening to cover the issue:
"Don't try to backup a site provision cannot access."
The branch pushed fixes this: It first checks if drush can bootstrap the database. Then it makes a backup. If it can't, it throws a warning that there was no DB to delete.
Comment #15
Jon PughComment #16
Jon PughThis has been working great on devshop for a long time: https://git.drupalcode.org/project/provision/compare/7.x-3.x...2666158-d...
Comment #18
Jon PughComment #19
colanSo do we still need https://www.drupal.org/project/hosting_dev ? Or is it no longer useful now that this stuff is fixed?