allow upgrade of hostmaster sites from the frontend

we can only do this once we have the queue out of hostmaster.

If this is done it should be in HEAD

Closed #454312: self-provisionning support as a duplicate of this issue.

Here's a first stab at this, currently adding it to hosting_tasks_extra but could be just as well to the hosting module.

It adds a new task type to just the hostmaster site which in the backend triggers the existing hostmaster-migrate code.

TODO:

• cleanup the form, and add config options?
• • directory name
  • makefile option
  • working copy option
  • Version? stable or dev
• Warn about or handle the queued losing it's database

Neat! So, just to be clear, updating Provision would still be a manual process? FWIW, the more of the back-end code that we move into front-end drush/ dirs, the fewer updates to Provision will be required.

Yes, updating provision is out of scope here. When installed as Debian package we don't even have write access to those files.

Right, so how do we handle an upgrade where the backend needs an update too? It seems like we could pretty easily get ourselves in pretty serious trouble. Might there be some way, in hostmaster-migrate presumably, to flag that the new platform requires an upgrade to Provision, and fails gracefully? Does hosting.drush.inc get bootstrapped on a verify of the hostmaster platform? Maybe something like this could work:

 # in provision.drush.inc

/**
 * Return the current version of Provision.
 */
function provision_version() {
  return file_get_contents('VERSION');
}

 # in hosting.drush.inc

define('HOSTING_MINIMUM_PROVISION_VERSION', '3.5');

/**
 * Implements hook_drush_init().
 */
function hosting_drush_init() {
  if (version_compare(provision_version(), HOSTING_MINIMUM_PROVISION_VERSION) < 0)) {
    drush_set_error('HOSTING_MINIMUM_PROVISION_VERSION', 'This version of Hosting requires an upgrade to Provision before proceeding.');
  }
}

Adding such a version check sounds like a good idea.

I'm not sure that the new platform is bootstrapped early enough...

drush_provision_hostmaster_migrate_validate calls provision-verify on the new platform which calls drush make. So I guess we could add some checking code at the end of that function.

hosting_drush_init()

wouldn't be bootstrapped at the platform level. However, maybe we can add the minimum Provision version to sites/all/drush/drushrc.php, since that'd make it easy to access. For example, this works:

$ drush @platform_hostmaster eval "drush_print_r(drush_get_option('profiles'));"
Array
(
    [0] => minimal
    [1] => standard
    [2] => hostmaster
)

#2648450: hosting_queued fails to restart itself seems to have now solved the queued part.