Attempt to start and manage PostgreSQL service even if init system fails

[vutny]

This PR adds couple of fall back states to make sure that PostgreSQL service will be enabled and started even if service.running module fails to do its job.

Why we need such a thing? This adds a possibility to fully provision PostgreSQL with all supported entities during the build process of AMI/VM/Container images (using Packer or Docker for example).

Before this PR that didn't work, because:

• in order to create databases, users, etc you need a running cluster
• Salt relies on running init system (systemd, Upstart, SysV) to launch PostgreSQL processes
• there is actually no init process running in the scope of the image build, so PostgreSQL cluster fails to start and all subsequent states fail as well

Also, this is a move towards resolving issue #125 by removing the osmajorreleasemap.yaml file mapping and making a PostgreSQL cluster command as general as possible across different distributions and major versions.

[vutny]

I made the final changes for the state to run clear without any failures even if init system is not available and Salt wouldn't be able to start and enable PostgreSQL server via service.running state function.

This makes the formula fully compatible and working with newest Salt functionality:
https://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.dockerng.html#salt.modules.dockerng.sls_build

@javierbertoli , please could you review my changes? Thanks!

[javierbertoli]

Hi @vutny. I'm still trying to make up my mind about this PR. I DO get the idea and understand the spirit of it, but I feel the implementation is not the best or might lead to errors somehow...

Thinking out loud: how about moving all these resources ('docker/packer/containerized' needs) to their own sls file, which can be included as a dependency in server.sls based on a parameter, say server_manual_start (or similar)? That way, things will be clearly separated, will depend on an explicit desire of manually starting the server (and not of a grain discovery)?

As I said, I'm not even convinced my idea is ther ight one, so I'm completely open to reading whatever you have to say 😄

[vutny]

@javierbertoli I understand your concern. Indeed it would be better to get this behavior configurable, not just assume that everybody will need the feature. I've used Grain switch because I wanted just apply the formula and get the same result which does not depend on any environment specific Pillars. But adding some toggling setting for this is definitely doable.

Regarding the separation of states which handle the manual start of PostgreSQL (this is the only additional thing required for "baking" appliances), right now I'm not sure if it wouldn't make implementation of this too much complicated. Because the states really closely coupled with all the things done before in server.sls. But I will try to think how that could be addressed properly.

I will come up with further changes to address your comments. Thanks.

[vutny]

@javierbertoli , I think I made it... better than the initial implementation.
I've added bake_image Pillar settings which controls how we handle PostgreSQL startup behavior, i.e. do it image build specific if set True. Also I have separated the states in the postgres.server.image SLS file and add the include in postgres.server SLS depending on the Pillar from above.
All this stuff has been documented in README and pillar.example as well.

I hope this is good to go. Thanks!

[javierbertoli]

@vutny it looks great to me. Thanks for all your hard work!