For development, sometimes it's useful to examine a site where an install failed, but Aegir does too good of a job in its rollbacks :)

Dropping a drush_clear_error() at the end of platform/install.provision.inc will still show that the install task had errors (that is, the task status is 'Failure'), but won't perform the rollback, deleting the db, etc. Cleaning this up afterwards is manual though. So we should really implement a site 'purge' feature, or something too.

It'd be nice to provide an option to allow the install process to ignore errors like that. I don't know that it'd be appropriate for Aegir core though. I think all we'd need to implement a solution in contrib would be a hook at the end of drush_provision_drupal_provision_install() to allow us to call drush_clear_error().

Comments

helmo’s picture

helmo CreditAttribution: helmo commented

A related drush issue:
#1101142: Option to prevent automatic rollback

It's been a while since I've tried this... but running a task manually from the shell should allow you to add the confirm-rollback option.

ergonlogic’s picture

ergonlogic
he/him
Primary language English
Location Montréal, Québec 🇨🇦
CreditAttribution: ergonlogic commented

Ooh, interesting. A recent example of the utility here is installing openatrium-2.0-beta4. It throws a couple errors during the install, but nothing catastrophic, but the site fully installs otherwise. Stopping the rollback provides a usable site. In fact, it looks like the Drush 5.9 missing back-end packets didn't set the error status on a recent install attempt, and so the site remained. It'd be nice to be able to do that on purpose :)

helmo’s picture

helmo CreditAttribution: helmo commented

This issue?
#2080999: WD cron: EntityFieldQueryException: Unknown field: field_oa_date in EntityFieldQuery->addFieldCondition

My log there shows no rollback is done. I ran an 'Enable' task to get Aegir to further work with the site.

Jon Pugh’s picture

Jon Pugh
he/him
Primary language English
Location Newburgh, NY
CreditAttribution: Jon Pugh commented
Priority: Normal » Major
Issue summary: View changes

I need this to be possible permanently across hostmaster.

Clones fail when I clone in devshop because I cannot run deploy hooks (registry rebuilds, etc). Installs can fail all the time when you are developing them.

Lets start by documenting how to use the confirm-rollback option, then I'll try to find a way to be able to set it hostmaster wide.

I also think this needs to be an easy switch for users to throw. The UX for dealing with a rollback is really bad.

We should default to not roll back. For those of us that really need it, it should be an easy switch.

helmo’s picture

helmo CreditAttribution: helmo commented

@Jon Pugh I don't agree that we should disable rollback by default. This would leave the mess from an unexpected failure up to a user to clean up.

But +1 is you want to make a setting that a debugging admin can toggle.

Jon Pugh’s picture

Jon Pugh
he/him
Primary language English
Location Newburgh, NY
CreditAttribution: Jon Pugh commented

Thanks, helmo,

Could you post more details about how you got this working?

Thanks.

helmo’s picture

helmo CreditAttribution: helmo commented

I think I ran the task manually from the command line.

E.g.
drush --confirm-rollback hosting-task 42

Jon Pugh’s picture

Jon Pugh
he/him
Primary language English
Location Newburgh, NY
CreditAttribution: Jon Pugh commented

I am dealing with a site clone task...

Answering "no" when asked to roll back does not prevent the new site from being deleted...

Jon Pugh’s picture

Jon Pugh
he/him
Primary language English
Location Newburgh, NY
CreditAttribution: Jon Pugh commented

Related: #2666158: Allow --force option on Delete tasks.

Jon Pugh’s picture

Jon Pugh
he/him
Primary language English
Location Newburgh, NY
CreditAttribution: Jon Pugh commented

Was thinking this might help for removing sites where deletion "failed" because there is nothing to delete.

It did not.

helmo’s picture

helmo CreditAttribution: helmo at Initfour websolutions commented
Priority: Major » Normal

#2754069: API Only: Allow site nodes to specify "install_method", allowing something other than automated Drupal profile. might be useful here ... to manually try a failing install.