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.
(where appropriate)
- add missing 'requires' on database objects (schemas require databases,
databases require users, etc....)
- alter structure of schema and extension configuration:
now schema and extension configuration follows the other items in that
they are expected to be *dictionaries* where the key is the name of
the object and the value is another subdictionary of configuration.
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']
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
Add temporary states/modules for handling tablespaces in Postgresql. These will
be fed back upstream, but they can live here for now.
Add support for the states/modules to the formula.
