database subresoruce not working when using option_collector

[chrodriguez]

I have deployed an application_ruby resource using the folloging sintax and it's not writting database name in config/database.yml

application '/opt/applications/xxx' do
  rails do
    database do
      adapter: 'mysql2'
      username: 'user'
      host: '127.0.0.1'
      database: 'name'
      password: '
    end
  end 
end

So changing the above configuration with the following now is working:

application '/opt/applications/xxx' do
  rails do
    database(
      adapter: 'mysql2',
      username: 'user',
      host: '127.0.0.1',
      database: 'name',
      password: 'password',
    )    
  end 
end

Basically, the first case generates a database.yml without database name. The second one is working

[coderanger]

That is correct, the option collector syntax would be without the colons:

    database do
      adapter 'mysql2'
      username 'user'
      host '127.0.0.1'
      database 'name'
      password ''
    end

[chrodriguez]

My mistake when explaining the problem. I've used it without collons as you mention:

   database do
      adapter 'mysql2'
      username 'user'
      host '127.0.0.1'
      database 'name'
      password ''
    end

in that case, databse key is not written into the database.yml file

[coderanger]

Please link the full recipe somewhere.

[ljfc]

Hi, not sure if I should raise a new issue for this, but I was having the same problem as @chrodriguez where only the database property was not being written into database.yml, and after reading his solution I was able to fix it too, but this seems like a bug.

I’ve put the broken / working versions in this gist. The problem is definitely isolated to just these lines:

rails do
  rails_env app['environment']['RAILS_ENV']
  database do
    adapter 'mysql2'
    host db['address']
    username db['db_user']
    password db['db_password']
    database db['db_instance_identifier']
  end
end

I’ve had a look inside the application_ruby files that generate database.yml but I confess I’m a bit confused as to where the values get picked up. I can see where they get merged with the defaults, and the actual template generation (which must work as the hash-based version does fill it in). Is there some metaprogramming happening here which might be picking up the database collector option and treating it differently because the parent resource has the same name?

I’m using version 4.0.1 and Chef 12.7.2.

[coderanger]

@ljfc At least at first glance, your code looks correct. If possible I would throw a binding.pry into the collector block and see what it thinks db means. It should be a closure around the variable above, but Ruby can be weird sometimes :-(

[ljfc]

Thanks @coderanger.

I’ve tried today to get a debugging session going on the server, but I’m running this all on AWS OpsWorks, and despite quite a bit of poking around on a test instance I can’t get an interactive chef session going... (seems like a bunch of path config is needed, and maybe some private keys from OpsWorks, but I’m pretty new to all this and not really sure).

Since it is working now in practice I think this will have to remain a mystery...

Thanks again, really appreciate all your work on these recipes, they’ve been a lifesaver.