Database options are partially ignored/not respected

[mitom]

When trying to use the cookbook on a database where the user is non-existent on the instance running this, it runs into errors due to trying to run some commands as the database user.

It also partially ignores the database.name, it's not set in the environment and therefore it is omitted when running psql without any arguments, which will cause an error like (username replaced). Why is it even setting those in the environment instead of just writing them as arguments..? Makes it harder to debug, not seeing the arguments of the command failing - the exception being the password.

error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '2'
        ---- Begin output of echo 'CREATE EXTENSION IF NOT EXISTS pg_trgm' | psql ----
        STDOUT:
        STDERR: psql: FATAL:  database "<database.user>" does not exist
        ---- End output of echo 'CREATE EXTENSION IF NOT EXISTS pg_trgm' | psql ----

This is consistent with the default postgres behaviour where the database will be the name of the user, unless specified.

[robbkidd]

The cookbook internal to the Supermarket omnibus install uses the enterprise cookbook to perform database setup. The enterprise cookbook uses some of the PG command line tools to perform its actions and—at the current version being used—those CLI commands use PG_* environment variables to receive configuration. The omnibus' database recipe should have created a user in postgres based on what you have set node['supermarket']['database']['user'] (defaults to supermarket).

[robbkidd]

Are you customizing the name of the database user? If so, how are you setting that customization?

[mitom]

@robbkidd The problem is not that the user does not exist in postgres, it is that it does not exist on the system (which should not be expected in my opinion). The source of this is apparent when you look at the recipe. It tries to use the node['supermarket']['database']['user'] attribute as the user in an execute block, which means it will try to run a shell command as that user on the system, not in postgres.

Yes, I customize the values for these, through a wrapper cookbook that pulls these from an encrypted databag:

secrets = data_bag_item('applications', 'chef-supermarket')

node.override['supermarket_omnibus']['chef_server_url'] = secrets['chef_server_url']
node.override['supermarket_omnibus']['chef_oauth2_app_id'] = secrets['chef_oauth2_app_id']
node.override['supermarket_omnibus']['chef_oauth2_secret'] = secrets['chef_oauth2_secret']
node.override['supermarket_omnibus']['config']['postgresql']['enable'] = false
node.override['supermarket_omnibus']['config']['database']['user'] = secrets['database_user']
node.override['supermarket_omnibus']['config']['database']['password'] = secrets['database_password']
node.override['supermarket_omnibus']['config']['database']['name'] = secrets['database_name']
node.override['supermarket_omnibus']['config']['database']['host'] = secrets['database_host']
node.override['supermarket_omnibus']['config']['database']['port'] = secrets['database_port']
node.override['supermarket_omnibus']['config']['s3_bucket'] = secrets['s3_bucket']
node.override['supermarket_omnibus']['config']['s3_region'] = secrets['s3_region']
node.override['supermarket_omnibus']['config']['s3_access_key_id'] = secrets['s3_access_key']
node.override['supermarket_omnibus']['config']['s3_secret_access_key'] = secrets['s3_secret_key']

include_recipe 'supermarket-omnibus-cookbook'

I can verify that this all works, as doing the following as a work around solves the issue:

1. Use the exact same value for database name and username for postgres.
2. Create the postgres user on the system as well.

While this works, I think this is still something that should be fixed.

[robbkidd]

A-ha. I see.

node.override['supermarket_omnibus']['config']['postgresql']['enable'] = false
node.override['supermarket_omnibus']['config']['database']['user'] = secrets['database_user']

Additional reproduction info: you're using a PG separate from the Supermarket omnibus install. We'll investigate what we can do to make the database setup more flexible for that should-absolutely-be-supported scenario.