When postgres_database.present tries to create a database and assign it to a user, it always fails with a python exception and a stack trace.
----------
ID: postgres_database-provisioner_local
Function: postgres_database.present
Name: provisioner_local
Result: False
Comment: An exception occurred in this state: Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/salt/state.py", line 1745, in call
**cdata['kwargs'])
File "/usr/lib/python2.7/dist-packages/salt/loader.py", line 1702, in wrapper
return f(*args, **kwargs)
File "/usr/lib/python2.7/dist-packages/salt/states/postgres_database.py", line 98, in present
dbs = __salt__['postgres.db_list'](**db_args)
File "/usr/lib/python2.7/dist-packages/salt/modules/postgres.py", line 461, in db_list
password=password)
File "/usr/lib/python2.7/dist-packages/salt/modules/postgres.py", line 417, in psql_query
password=password)
File "/usr/lib/python2.7/dist-packages/salt/modules/postgres.py", line 364, in _psql_prepare_and_run
rcmd, runas=runas, password=password, host=host, port=port, user=user)
File "/usr/lib/python2.7/dist-packages/salt/modules/postgres.py", line 181, in _run_psql
ret = __salt__['cmd.run_all'](cmd, python_shell=False, **kwargs)
File "/usr/lib/python2.7/dist-packages/salt/modules/cmdmod.py", line 1649, in run_all
**kwargs)
File "/usr/lib/python2.7/dist-packages/salt/modules/cmdmod.py", line 394, in _run
'User \'{0}\' is not available'.format(runas)
CommandExecutionError: User 'provisioner_local' is not available
Started: 14:44:29.277236
Duration: 5.524 ms
Changes:
Using postures-formula from saltstack-formulas at revision 5cbf920fa7f7d277a5dd874f08157f15aad3a19e
Pillar Data:
postgres:
#pg_hba.conf: salt://postgres/pg_hba.conf
conf_dir: /etc/postgresql/9.4/main
lookup:
pkg: 'postgresql-9.4'
pkg_client: 'postgresql-client-9.4'
pkg_dev: 'postgresql-server-dev-9.4'
pkg_contrib: 'postgresql-contrib-9.4'
pg_hba: '/etc/postgresql/9.4/main/pg_hba.conf'
version: 9.4
users:
provisioner_local:
password: 'blabla'
createdb: False
acls:
- ['host', 'provisioner_local', 'provisioner_local', '0.0.0.0/0', 'md5']
databases:
provisioner_local:
owner: 'provisioner_local'
user: 'provisioner_local'
template: 'template0'
lc_ctype: 'C.UTF-8'
lc_collate: 'C.UTF-8'
postgresconf: |
listen_addresses = '0.0.0.0'
State:
local:
- postgres
Running salt-call state.apply will do everything correctly except creating the database (and setting the user as the owner). The user is created fine. This issue has been happening since Debian 8 and Salt 2016.3.x
Postgres says:
postgres=# \du
List of roles
Role name | Attributes | Member of
-------------------+------------------------------------------------+-----------
postgres | Superuser, Create role, Create DB, Replication | {}
provisioner_local | | {}
This is done in a fresh vagrant box, and fails every time.
Salt Version:
Salt: 2016.11.2
Dependency Versions:
cffi: 1.9.1
cherrypy: 3.5.0
dateutil: 2.5.3
gitdb: 2.0.0
gitpython: Not Installed
ioflo: Not Installed
Jinja2: 2.8
libgit2: 0.24.5
libnacl: 1.5.0
M2Crypto: 0.24.0
Mako: 1.0.6
msgpack-pure: Not Installed
msgpack-python: 0.4.8
mysql-python: 1.3.7
pycparser: 2.17
pycrypto: 2.6.1
pygit2: 0.24.2
Python: 2.7.13 (default, Jan 19 2017, 14:48:08)
python-gnupg: 0.3.9
PyYAML: 3.12
PyZMQ: 16.0.2
RAET: Not Installed
smmap: 2.0.1
timelib: Not Installed
Tornado: 4.4.3
ZMQ: 4.2.1
System Versions:
dist: debian 9.0
machine: x86_64
release: 4.9.0-3-amd64
system: Linux
version: debian 9.0
Supplemental information:
On top of those, setting the user post-database creation (i.e. doing it manually first) also doesn't work. Something seems to be problematic with getting available users.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.
This is still a severe bug...
Thank you for updating this issue. It is no longer marked as stale.
Any update on this?
I have not seen or heard anything. Probably worth re-verifying this to be sure?
Most helpful comment
This is still a severe bug...