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.
