The reworks in merge #110 broke this formulas kitchen based specs.
This MR changes a few minor things, mostly pillar.example and other inconsistent documentations.
Also, the use of db_user for `postgres_tablespace.present` and `postgres_database.present` now fits the states options, as db_password etc can be specified as well.
which control three things:
1. should we initialize?
2. if so, how?
3. what environment variables and user to use
The approach taken is very similar to what the Apache formula uses, namely:
a default dictionary which is over-ridden by:
os-specific defaults,
then os codename defaults,
then os finger defaults,
and finally user-specified pillar values
- this also adds support for grains['osfinger']
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
