Closed (fixed)
Project:
Provision
Version:
6.x-0.4-alpha1
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
7 Oct 2009 at 00:28 UTC
Updated:
12 Jun 2014 at 08:41 UTC
Jump to comment: Most recent
Comments
Comment #1
anarcat commentedThat is a bug: this should fail with a message that the site exists. I don't see this as a critical issue however.
Comment #2
Anonymous (not verified) commentedI think I can fix this by using
_provision_drupal_site_installed($url)indrush_provision_drupal_provision_install_validate($url). I'll update if it worksComment #3
Anonymous (not verified) commentedExcept a bigger problem emerges: when _validate fails, and _rollback runs, the sites/www.whatever.com is deleted :) which is not what you want when it is detected that the site already exists! This means that the _rollback implementation will need to be changed.. maybe. hum.
Comment #4
Anonymous (not verified) commentedI have it working if I add a check to see if the site is installed in the _rollback implementations, for instance in platform/install.provision.inc (leaving the previous conditional but commented out so you can see)
and again in db_server/install.provision.inc (so that rollback when the existing site is found, doesn't drop the db / grants)
That way it will only run the rollback if the site was not yet finished installing (i.e it depends on drush_get_option('installed');), and all this occurs if it triggers the problem in the hook_validate:
However I don't know if this is the right way (can we rely on the idea that in any *other* case where an install might fail (whether or not a site of the same name exists), the context will report 'installed' by that point, so that proper rollback WILL occur ). For this reason I haven't committed/submitted a patch for review yet, I'm unsure if this is the right way to go about it.
Comment #5
Anonymous (not verified) commentedhttp://git.mig5.net/?p=modules/provision/.git;a=commitdiff;h=refs/heads/...
Comment #6
anarcat commentedPush to head, thanks mig5!
Comment #7
anarcat commentedSo I reverted that commit in the end, it introduces a regression where the site_id is not passed to the backend properly, which breaks backups, amongst other things, and create a silly drushrc.php:
Backups break like this:
Comment #8
anarcat commentedThe only explanation I could think of here is this:
... ie. that _provision_drupal_site_installed() would do something special.
Note that I'm running provision HEAD + Hostmaster 0.4-alpha3.
Comment #9
Anonymous (not verified) commentedanarcat fixed this stupid regression of mine, tested and works as expected.