Deploying a 2nd time causes drush to hang

[unityweb]

What can bw wrong there ?

Error executing action run on resource 'execute[drush_en_module views]'

Mixlib::ShellOut::ShellCommandFailed

Expected process to exit with [0], but received '1' ---- Begin output of /usr/local/drush/drush -y en views ---- STDOUT: STDERR: Command pm-enable needs a higher bootstrap level to run - you will [error] need invoke drush from a more functional Drupal environment to run this command. The drush command 'en views' could not be executed. [error] Drush was not able to start (bootstrap) the Drupal database. [error] Hint: This error often occurs when Drush is trying to bootstrap a site that has not been installed or does not have a configured database.

Drush was attempting to connect to : Drupal version : 7.14 Site URI : http://default Database driver : mysql Database hostname : localhost Database username : drupal Database name : drupal Default theme : garland Administration theme: garland PHP configuration : /etc/php5/cli/php.ini Drush version : 5.4 Drush configuration: Drupal root : /var/www/drupal Site path : sites/default Modules path : sites/all/modules Themes path : sites/all/themes File directory path: sites/default/files %paths : Array

You can select another site with a working database setup by specifying the URI to use with the --uri parameter on the command line or $options['uri'] in your drushrc.php file. ---- End output of /usr/local/drush/drush -y en views ---- Ran /usr/local/drush/drush -y en views returned 1

[mdxp]

This indicated that drupal was not installed correctly. Please verify that and see if that is the case.

[dkinzer]

This was happening to me too, but then It started working once I added overrides for drupal attributes.

override_attributes(
  "mysql" => {
    "server_root_password" => "iloverandompasswordsbutthiswilldo",
    "server_repl_password" => "iloverandompasswordsbutthiswilldo",
    "server_debian_password" => "iloverandompasswordsbutthiswilldo"
  },
  "drupal" => {
    "db" => {"password" => "drupalpass2"},
    "dir" => "/var/www/html/cdb"
  },
  "hosts" => {
    "localhost_aliases" => ["cdb.dev", "cdb-dev", "localhost"]
  }
)

default_attributes(
  "apache2" => {
    "listen_ports" => ["80", "443"]
  }
)

I think that for some reason the cook-book defaults do not work.

[mdxp]

What attribute was needed to be overwritten? the mysql passwords?

[dkinzer]

@mdxp I haven't figured that out yet. I just noticed that you override these in your Vagrantfile's Chef provisioning section so I thought I would try that, and that worked for me.

[mdxp]

I can assume the mysql password is the issue. Let me know what you found out.

[dkinzer]

@mdxp sorry I couldn't get back to this earlier.

You're absolutely correct. The problem has to do with node['drupal']['db']['password'].

In the default attributes file , the password is set with set_unless['drupal']['db']['password'] = secure_password

Which means that in the case that someone did not provide an override for the password, there is a conflict the second time one cooks because presumably secure_password does not return the same password it gave the first time.

I can reproduce the issue another way: which is to override the db password before the first time I provision the VM. The next time I run cook without changing the password nothing happens. However, if I modify my config file to change the password for the db, then the build fails.

If I then revert the password in the configuration to the original password, and cook again, the build does not fail.

So the bug is that as it stands, the recipe does not know how to handle a change in the database password.