We currently allow Aegir to be installed on a remote database server, but the hostmaster-migrate command hardcodes '@server_master' as the db_server. We should support (at least):

  1. Keeping @hostmaster installed on a remote DB server across upgrades.
  2. Moving @hostmaster to a remote DB server.

The first step will be fixing the hostmaster-migrate command to maintain the current DB server (even if it's remote). Next, we should support migrating to a remote DB server. Finally, these options should be integrated into our Debian package. Of course, docs should be upgraded to reflect this too.

Comments

ergonlogic created an issue. See original summary.

ergonlogic’s picture

ergonlogic
he/him
Primary language English
Location Montréal, Québec 🇨🇦
CreditAttribution: ergonlogic at Ergon Logic Enterprises for Aegir Cooperative commented
Assigned: Unassigned » ergonlogic

Note, I've marked this as 'major' since it can break the Aegir site in ways that would be very difficult to fix.

Also, I'm assigning to me, since I plan to work on this today, as we have a volunteer to test this functionality on a live Aegir deployment (once it's ready, of course.)

karel010’s picture

karel010 CreditAttribution: karel010 commented

We probably want the options to be the same as hostmaster-install:
--aegir_db_host Database host to connect to (default: localhost)
--aegir_db_pass Database password to use
--aegir_db_port Database port to use (default: 3306)
--aegir_db_user Database user to connect as (default: root)

What do we rely on for source data (current db settings)? The @hostmaster context seems the obvious choice but the hostmaster-migrate command seems to work with the name of the site. Are there situations where @hostmaster should not be used?

ergonlogic’s picture

ergonlogic
he/him
Primary language English
Location Montréal, Québec 🇨🇦
CreditAttribution: ergonlogic at Ergon Logic Enterprises for Aegir Cooperative commented

The initial implementation will probably mirror provision-migrate, and accept a --new_db_server. Accepting the individual DB credential options allows for potentially creating a new database server node in Aegir, but this would be more complicated and error-prone.

ergonlogic’s picture

ergonlogic
he/him
Primary language English
Location Montréal, Québec 🇨🇦
CreditAttribution: ergonlogic at Ergon Logic Enterprises for Aegir Cooperative commented

I've created a new branch to track these efforts: dev/2729279. The first commit adds the --new_db_server option to hostmaster-migrate, and works to move the site to the new db server. At this point, this setting only exists in the db credentials, as both the alias (context) and the front-end still think the site is on localhost.

ergonlogic’s picture

ergonlogic
he/him
Primary language English
Location Montréal, Québec 🇨🇦
CreditAttribution: ergonlogic at Ergon Logic Enterprises for Aegir Cooperative commented

This call to hosting-resume, in drush_provision_post_hostmaster_migrate(), appears to be causing the db_server to revert to @server_localhost for @hostmaster.

  provision_backend_invoke(drush_get_option('site_name'), 'hosting-resume', array(), array(
    'old_platform_name' => drush_get_option('old_platform'),
    'new_platform_name' => drush_get_option('new_platform'),
  ));

Commenting it out allows the proper db_server to be registered in @hostmaster...

ergonlogic’s picture

ergonlogic
he/him
Primary language English
Location Montréal, Québec 🇨🇦
CreditAttribution: ergonlogic at Ergon Logic Enterprises for Aegir Cooperative commented

I've added a dev/2729279 branch to hosting as well, since the hosting-resume command appears to be where the difficulties lie.

colan’s picture

colan
he/him
Primary language English
Location Toronto 🇨🇦
CreditAttribution: colan at Consensus Enterprises for Health Canada - HPFB commented

See also #2849124: Validation for remote hostmaster fails.