Closed (outdated)
Project:
Provision
Version:
7.x-3.x-dev
Component:
Code
Priority:
Major
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
4 Mar 2011 at 17:04 UTC
Updated:
16 May 2017 at 11:32 UTC
Jump to comment: Most recent
Comments
Comment #1
shaneonabike commentedHere's the log file for your info - it exploded b/c the temporary directory wasn't big enough - egads.
Comment #2
anarcat commentedThe way this works right now is that the verify is hooked into the platform class through a magic "command_invoke" hook in provision.drush.inc:
note how this magically hooks into *any* provision-verify command on *any* object and "command_invoke"s it. If this is a platform, it will call verify_platform_cmd() on the server/site/platform/whatever object that's being passed as an alias on the commandline. It's magic.
The problem is that there is no hook for rollback in there. We would need to redo the whole API to add a drush_provision_verify_rollback() hook in the drush.inc, then follow down that path into all the objects. This seems retarded to me - we should instead adapt to the existing rollback hooks in a cleaner way.
Note how, most of the time, this is used for server verification, so I'm not sure it's really worth abstracting all this that deep.
Nevertheless... I have added a rollback hook and tried to make a good implementation of it for http configs rollbacks for platforms. I hope this is now fixed, at least for platforms.
See http://drupalcode.org/project/provision.git/commit/f7a071135d626bcef4879...
Comment #3
anarcat commentedOkay no, it's harder than this.. I reverted that commit, with the message:
That issue is #1108152: Break out drush make calls in a new platform install task.
Comment #4
ergonlogicComment #5
helmo commented3+ years of silence ... please re-open if there is still a problem.