We have a serious problem with Drush 5 compatibility, that is better demonstrated with the following log:

found  running tasks, starting 2 out of 2 items                                                                                                                                                                                        [notice]
executing php /usr/share/drush/drush.php  --verbose --uri=aegir.anarcat.ath.cx --root=/var/aegir/hostmaster-6.x-2.x/ hosting-cron   --items=2 --context_type=site --platform='@platform_hostmaster6x2x' --server='@server_master'      [notice]
--db_server='@server_localhost' --site_path=/var/aegir/hostmaster-6.x-2.x//sites/aegir.anarcat.ath.cx --site_enabled --language=en --client_name=anarcat --redirection= --cron_key= --profile=hostmaster --ssl_enabled=0 2>&1
--quiet &
Calling proc_open(php /usr/share/drush/drush.php  --verbose --uri=aegir.anarcat.ath.cx --root=/var/aegir/hostmaster-6.x-2.x/ hosting-cron   --items=2 --context_type=site --platform='@platform_hostmaster6x2x' --server='@server_master' --db_server='@server_localhost' --site_path=/var/aegir/hostmaster-6.x-2.x//sites/aegir.anarcat.ath.cx --site_enabled --language=en --client_name=anarcat --redirection= --cron_key= --profile=hostmaster --ssl_enabled=0 2>&1 --quiet &);
found 0 running tasks, starting 5 out of 5 items                                                                                                                                                                                       [notice]
executing php /usr/share/drush/drush.php  --verbose --uri=aegir.anarcat.ath.cx --root=/var/aegir/hostmaster-6.x-2.x/ hosting-tasks   --items=5 --context_type=site --platform='@platform_hostmaster6x2x' --server='@server_master'     [notice]
--db_server='@server_localhost' --site_path=/var/aegir/hostmaster-6.x-2.x//sites/aegir.anarcat.ath.cx --site_enabled --language=en --client_name=anarcat --redirection= --cron_key= --profile=hostmaster --ssl_enabled=0 2>&1
--quiet &
Calling proc_open(php /usr/share/drush/drush.php  --verbose --uri=aegir.anarcat.ath.cx --root=/var/aegir/hostmaster-6.x-2.x/ hosting-tasks   --items=5 --context_type=site --platform='@platform_hostmaster6x2x' --server='@server_master' --db_server='@server_localhost' --site_path=/var/aegir/hostmaster-6.x-2.x//sites/aegir.anarcat.ath.cx --site_enabled --language=en --client_name=anarcat --redirection= --cron_key= --profile=hostmaster --ssl_enabled=0 2>&1 --quiet &);
Command dispatch complete                                                                                                                                                                                                              [notice]
aegir@marcos:/usr/share/drush$ Initialized Drupal 6.26 root directory at                               [notice]
/var/aegir/hostmaster-6.x-2.x/
Initialized Drupal site aegir.anarcat.ath.cx at                         [notice]
sites/aegir.anarcat.ath.cx
Initialized Drupal 6.26 root directory at                               [notice]
/var/aegir/hostmaster-6.x-2.x/
Initialized Drupal site aegir.anarcat.ath.cx at                         [notice]
sites/aegir.anarcat.ath.cx
Unknown options: --items, --context_type, --platform, --server,      [error]
--db_server, --site_path, --site_enabled, --language, --client_name,
--redirection, --cron_key, --profile, --ssl_enabled.  See `drush help
hosting-cron` for available options. To suppress this error, add the
option --strict=0.
Unknown options: --items, --context_type, --platform, --server,      [error]
--db_server, --site_path, --site_enabled, --language, --client_name,
--redirection, --cron_key, --profile, --ssl_enabled.  See `drush help
hosting-tasks` for available options. To suppress this error, add the
option --strict=0.

Basically, the problem is that drush flags are not accepted unless they are defined by the command. Since we use those flags all over the place, this is going to create significant issues... especially for commands like provision-save, for example.

Comments

anarcat’s picture

anarcat commented

It seems the problem is related with the way that drush_invoke_process works. It seems to explode the @self alias into its components instead of just calling the drush command with the alias. That seems to be a strange approach, if you ask me - we should just pass the alias along to the sub command. Granted, this may not work with remote servers, but right now this breaks if there is any variable defined in the alias that is not also a valid argument for the command being called on the said alias, which is very common in our use case.

greg.1.anderson’s picture

greg.1.anderson commented
Category: bug » support
Status: Active » Fixed

You can add the option 'invoke' => TRUE in the command options in backend invoke to overcome this feature if you do not want it. Since it was deemed to be kind of annoying to have to remember to do this, backend invoke automatically does it for you. It looks like you have your own command generator for hosting-cron; just add --invoke to your commandline options, or perhaps use drush_set_option('invoke', TRUE) if you are coming in through your own script instead of the 'drush' script, and you should be fine.

greg.1.anderson’s picture

greg.1.anderson commented

Regarding #1, Drush works this way because the alias used might not be defined on the remote systems. There has been some talk of passing the alias by reference if the target site is local, or if the caller explicitly asks for that behavior. Didn't look for the issue #, though.

anarcat’s picture

anarcat commented
Title: command arguments not defined for drush 5 » how to not explode aliases in drush_invoke_process
Project: Provision » Drush
Version: 6.x-2.x-dev » 7.x-5.3
Component: API » Core Commands
Status: Fixed » Needs work

Thanks very much for the feedback!

I have tried the following call:

              drush_invoke_process('@hostmaster', "hosting-" . $queue, array(), array('items' => $count), array('fork' => TRUE, 'invoke' => TRUE));

...and setting:

             drush_set_option('invoke', TRUE);

...right before the call. I have also tried passing --invoke to hosting-dispatch, no dice.

So how do I do this again? I couldn't find a reference to the "invoke" parameter here: http://api.drush.ws/api/drush/includes%21command.inc/function/drush_invo...

am i missing something?

anarcat’s picture

anarcat commented

As for #3 - doesn't drush assume there is no drush installed on remote servers when doing remote calls?

greg.1.anderson’s picture

greg.1.anderson commented

Regarding #4, 'invoke' is an ordinary command option, not a backend option, so the correct fix should be:

drush_invoke_process('@hostmaster', "hosting-" . $queue, array(), array('items' => $count, 'invoke' => TRUE), array('fork' => TRUE));

The drush_set_option would need to be done by the receiving end, but the above should work on the calling end.

drush sql-sync assumes that Drush is not installed on the receiving end (if %dump-dir and databases are set in the site alias file), but backend invoke assumes that the receiving end has the drush script.

anarcat’s picture

anarcat commented
Status: Needs work » Fixed

thanks, that works!

Status: Fixed » Closed (fixed)

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