It is just a variant of init_db. A more correct solution would be to
support configuring a different initdb command while passing values from
the pillar by default like version. This would make it truly generic but
is probably not achievable given current pillar self-referencing
capabilities (ie. none).
Thus, I decided to make it OS family specific since Debian provides its
own tools to manage clusters, etc. Gentoo also has a specific way to
initialize a new cluster which does not fit with commands.initdb so
the current if/elif would be extended when support is added for Gentoo.
Previous write up lead the two pillar settings overwriting each other in the same state.
We can now properly select whether to create a cluster and/or initialize a new database.
Also the commands will not fail if both settings are false as found on Debian family OSes
as this is taken care of by the packaging system for main cluster.
- Corrected inadvertent changes to postgres_user
- Fixed postgres_user
- Explicitly list the grain that we're filtering by even though it's
default
- Place *BSD user and runas into osmap instead of hardcoding
This commit adds support for database extensions via
salt.states.postgres_extension
When configuring database pillar data all you need to do is add (optional)
extension list with the extensions that you want the state to apply to specific
database. Example:
db1:
owner: 'localUser'
user: 'localUser'
template: 'template0'
lc_ctype: 'C.UTF-8'
lc_collate: 'C.UTF-8'
extensions:
- uuid-ossp
This will make sure `uuid-ossp` extension is enabled on `db1` database.
Updated pillar.example to include (optional) extensions
There should be a better way of doing this, as I'm hardcoding the version name into the config dir.
On Debian based systems, postgresql is configured in "clusters" using some Debian specific tools. The main cluster is called ... main, which is why the `conf_dir` has a suffix of `main`.
