Site db and user not being removed on site delete

I confirm the issue with local DBs too. Take a look at this task log:

Task starts processing
Running: php /var/hostmaster/drush/drush.php --root='/var/hostmaster/drupal-5.16' 'provision' 'delete' 'testgrant2.localhost' --backend
Drush bootstrap phase : _drush_bootstrap_drush()
Drush bootstrap phase : _drush_bootstrap_drupal_root()
Loading drushrc "/var/hostmaster/drupal-5.16/drushrc.php" into "drupal" scope.
Initialized Drupal 5.16 root directory at /var/hostmaster/drupal-5.16
Found command: provision delete
Initializing drush commandfile: provision_drupal
Initializing drush commandfile: provision_apache
Initializing drush commandfile: provision_mysql
Including /var/hostmaster/.drush/provision/platform/delete.provision.inc
Including /var/hostmaster/.drush/provision/dns_server/delete.provision.inc
Including /var/hostmaster/.drush/provision/web_server/delete.provision.inc
Including /var/hostmaster/.drush/provision/db_server/delete.provision.inc
Including /var/hostmaster/.drush/provision/platform/backup.provision.inc
Including /var/hostmaster/.drush/provision/db_server/backup.provision.inc
Drush bootstrap phase : _drush_bootstrap_drupal_site()
Initialized Drupal site testgrant2.localhost at sites/testgrant2.localhost
Loading drushrc "/var/hostmaster/drupal-5.16/sites/testgrant2.localhost/drushrc.php" into "site" scope.
Generating mysql dump for testgrant2.localhost.
mysqldump -hlocalhost -usite_380 -p6Rfn6LMLW5 -rsites/testgrant2.localhost/database.sql site_380
Adding sites directory to /var/hostmaster/backups/testgrant2.localhost-2009-05-09_1.tar
cd /var/hostmaster/drupal-5.16/sites/testgrant2.localhost; tar -rf /var/hostmaster/backups/testgrant2.localhost-2009-05-09_1.tar *
gzip /var/hostmaster/backups/testgrant2.localhost-2009-05-09_1.tar
Removing task from hosting queue
Command dispatch complete

It just does the backup, but no delete.

So I think I fixed this in the latest HEAD. I tested only with localhost this time, please test again with a remote SQL server.

I confirm that issue on localhost installs.

So I have made a patch with basically finished off the patch #337485: allow configuration of the 'host' part of the created mysql users. It seems I forgot quite a few places that were using the host part of the URL.

So I have refactored the "dbclient" guessing in a function and used it everywhere relevant.

I would appreciate if this could be tested before it hits the tree as it is quite invasive.

To clarify, the patch takes care of fixing all the incorrect usages of $db_host in the code. $db_host is the name of the SQL server and it should never be confused with what we now call the $db_client, which is the host the server will appear to connect from. $db_client is usually web_ip or web_host

Maybe that should be part of provision_drush_init() instead of being duplicated in two functions, but I stick to the agile principle of not refactoring too much, especially since an eventual $db_client option would be a duplicate of the web_ip / web_host combo.

Actually, even with the patch, the user is not deleted. I must have missed something.

Oh my god. MySQL is so awful. Believe it or not, revoking the GRANT is not enough. You also need to DROP USER:

http://dev.mysql.com/doc/refman/5.0/en/drop-user.html

So I have to add this complicated piece of code to see if the user has a GRANT or not.

I'm going to commit this. It is necessary for the users to be removed properly, regardless of #337485: allow configuration of the 'host' part of the created mysql users. I would like testing, but I'm confident this is solid now.