On several hostmasters since the release of 3.160 I've found that migrations are not possible between platforms. I've tried with a couple of different platforms (D7 & D8), and some imported through the interface, others by command line. All migrations fail quickly with the error: There are no valid install profiles on the target platform to migrate to

I verified that in the hostmaster interface both platforms have the same install profiles: minimal and standard (no special install profiles being used).

Here's a copy of the output from task in the hostmaster interface:

Task starts processing: Migrate Site: example.com
-
	queue
Returned from hook drush_hosting_task_validate	
-
	debug
Calling hook drush_hosting_alias_pre_hosting_task	
1 s.
	debug
Returned from hook drush_hosting_alias_pre_hosting_task	
-
	debug
Calling hook drush_hosting_clone_pre_hosting_task	
-
	debug
Returned from hook drush_hosting_clone_pre_hosting_task	
-
	debug
Calling hook drush_hosting_migrate_pre_hosting_task	
-
	debug
There are no valid install profiles on the target platform to migrate to	
-
	error
Returned from hook drush_hosting_migrate_pre_hosting_task	
-
	debug
Command dispatch complete	
-
	notice
Updated task status to "Failed"

However, running migrations from the command line works, eg: drush @example.com provision-migrate --verbose --debug @platform_mynewplatform. Since it works I'm not going to post the output unless you all think it will be interesting.

CommentFileSizeAuthor
#4 3001670-migrate-profile-check.patch580 byteshelmo
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

kienan created an issue. See original summary.

kienan’s picture

I think this is caused by commit: 43fa468915a8f77b463da330dd93b924c183cad4

While it's true that the documentation on hosting_package_isntance_load returns an array, it seems to be returning an object in my tests on 3.160.

I think by default count() on an object will return 1 meaning that the previous conditions worked (sort of), whereas the new ones fail when an object is received but not an array. Also note: in hosting_migrate.drush.inc

if (is_array($profile_instance) && count($profile_instance)) {                                     
   $task->options['profile'] = $profile_instance->short_name;
}
else {
  .....

The code for assigning the profile assumed the profile_instance is an object, not an array.

The underlying bug is perhaps that hosting_package_load_instance does not return an array as the new conditions expect, but there will maybe be a couple of further changes since the existing code generally seems to assume it's an object instead.

kienan’s picture

Btw, I added some debug lines around hosting_migrate.drush.inc to get a clearer picture of the data being return:

Calling hook drush_hosting_migrate_pre_hosting_task	

Getting target profile name for profile node: 61	

target_platform: 46847 ; profile_short_name: standard	

Got profile_instance: stdClass Object ( [iid] => 39419 [version] => 8.6.1 [version_code] => 80600000500 [schema_version] => 0 [status] => 0 [rid] => 46847 [package_id] => 61 [package_type] => profile [nid] => 61 [description] => Install with commonly used features pre-configured. [short_name] => standard [old_short_name] => default [title] => Standard [type] => platform [languages] => Array ( [en] => English ) ) 
helmo’s picture

Status: Active » Needs review
FileSize
580 bytes

Thanks for digging into this ... this patch should do it.

kienan’s picture

Applied and migrations work as expected now.

Thanks!

kienan’s picture

Status: Needs review » Reviewed & tested by the community
jlab’s picture

Tried the patch and it fixed the issue for me as well, thanks!

  • helmo committed 2822a77 on 7.x-3.x
    Issue #3001670 by helmo, kienan: Unable to migrate sites on 3.160: There...
helmo’s picture

Status: Reviewed & tested by the community » Fixed
colan’s picture

Is this bad enough that we need to cut another release soon? Is everybody affected (critical)?

cableman0408’s picture

Can confirm the issue using custom profile and that the patch fixes it.

SocialNicheGuru’s picture

Thank you for this.

I have been having this issue for a long time.

Please re-roll to include

ac’s picture

Yes I would say this is critical and requires a release. Combined with latest Drupal core release should be done ASAP.

millenniumtree’s picture

Patch works well. Testing in PHP 7.2 with a Drupal 6 site (I know, I know...)

colan’s picture

This should now be fixed in Thursday's (October 18th's) release, 3.161. Let us know if not.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

jacob.embree’s picture

This is fixed in hosting-7.x-3.161, but my Debian installation of aegir3-hostmaster version 3.161 used hosting version 7.x-3.160, so I had to download the update manually. It could be because I'm using a custom make file using echo "aegir3-hostmaster aegir/makefile string $HOME/.../aegir-custom.make" | sudo debconf-set-selections. It basically uses a patched Drupal, the latest dev of hostmaster, and a custom module. I guess this is probably my problem.

colan’s picture

#17: Please open a new issue if it's not.