Currently, the code compiles generates a long php command for execution. Then it calls the system exec() to execute an external php command.
This makes it hard to control if you want to put pieces of a remote script into the background and logging cannot utilize watchdog or drupal_set_message() to notify the user if a script failed.
Refactor the cloud_scripting_exec.inc and aws_cloud_bundle_instance_exec.inc so it is not called in an external process. I think we can accomplish this with a function that specifically executes a remote command. This can then be reused by both bundling and remote script execution and any other function that wishes to quickly execute something remotely. For example:
function _cloud_scripting_exec_remote_command($cloud_context, $instance_id, $command, $background = FALSE) {
$ssh_user_name = aws_cloud_get_ssh_user( $cloud_context, $instance_id);
$instance = cloud_get_instance($cloud_context, $instance_id);
$key_name = $instance['key_name'];
$instance_ip = $instance['dns_name'];
if ((($perm_file = _cloud_scripting_get_perm_file($instance_id, $key_name, $cloud_context)) != FALSE)) {
$cmd = CLOUD_SSH_PATH . ' ' . $ssh_user_name . '@' . $instance_ip . ' -i "' . $perm_file . '" -o \'StrictHostKeyChecking no\' ' . $command;
if ($background == TRUE) {
$cmd . ' &';
}
exec($cmd, $output, $retval);
return $retval;
}
return $FALSE;
}
Comments
Comment #1
baldwinlouie commentedchanging to feature request.
Comment #2
yas@Baldwin-san,
Nice idea. My suggestion is to integrate Drupal queue system by pushing the remote command; it might make it complicated and more efforts but we can follow the producer/consumer design pattern (producer = script exec request => queue => consumer = exec command). Probably we need to check the status of the execution, therefore we need in-queue and out-queue? Any thoughts?
--- yas
Comment #3
yas