Where is the task to install Postgres?

[MichaelDBA]

SUMMARY

Where is the task to install postgres binaries and initialize a cluster?

[Andersson007]

@MichaelDBA hi, no, there isn't. This collection only contains modules at the moment but it would be great to expand it with Ansible roles covering basic things like you mentioned.

[Andersson007]

@tcraxs @kostiantyn-nemchenko @hunleyd @klando what do you think if this collection should focus only on modules or maybe it should provide roles also?

[tcraxs]

@Andersson007 I would only focus on modules. There are already some very complex roles in galaxy which also searching for maintain help. Also if I look to the zabbix community stuff, this looks really nice, but it is also a lot of effort for "only" having simple server/client and proxy installation (and alos for testing all these options).

A PostgresSQL setup could look so different for the different needs that it will just explode the work and maintain for it.

But I do not want to hold people away from including something like this in that collection. If there are some people who are willing to do this and maintaining, please do so.

[klando]

I have a plan to propose roles to install, configure, initdb, tune, backup, restore, setup (physical/logical) replica, and so on (some will need new modules probably, pg_basebackup "mapping" for example) It can become very complex so probably it'll need to start with a limited scope (i.e. latest RedHat and Debian only for example).

[klando]

@Andersson007 I would only focus on modules. There are already some very complex roles in galaxy which also searching for maintain help. Also if I look to the zabbix community stuff, this looks really nice, but it is also a lot of effort for "only" having simple server/client and proxy installation (and alos for testing all these options).

A PostgresSQL setup could look so different for the different needs that it will just explode the work and maintain for it.

But I do not want to hold people away from including something like this in that collection. If there are some people who are willing to do this and maintaining, please do so.

Honestly I found c.zabbix very useful, and I put some effort in it. Major distinction: c.zabbix roles (but also modules) maintenance is a bit painful because regression where not very documented or not clearly mentioned upstream. PostgreSQL is very clean in this area and there will be no surprise.

[hunleyd]

@tcraxs @kostiantyn-nemchenko @hunleyd @klando what do you think if this collection should focus only on modules or maybe it should provide roles also?

I could go either way. It would be a fairly heavy lift though if we went down that path. It would have to be well defined and we'd need some lengthy discussions (for example even if we limit it to RH/Debian as @klando suggests, are we installing from their default repos or are we installing the PGDG repo and getting things from 'upstream'?).

[klando]

@tcraxs @kostiantyn-nemchenko @hunleyd @klando what do you think if this collection should focus only on modules or maybe it should provide roles also?

I could go either way. It would be a fairly heavy lift though if we went down that path. It would have to be well defined and we'd need some lengthy discussions (for example even if we limit it to RH/Debian as @klando suggests, are we installing from their default repos or are we installing the PGDG repo and getting things from 'upstream'?).

@hunleyd, very good question. And with many items as it is very flexible. I'm thinking already since some time on how to be effective here. I'll very probably propose documentation first and start from that, I'm all in favor of sensible default with minimal changes and also a set of defaults for the common cases (i.e. at least going with PGDG repos)

I'm expecting playbooks inside collections to be a very good friend for those purpose.

[hunleyd]

@hunleyd, very good question. And with many items as it is very flexible. I'm thinking already since some time on how to be effective here. I'll very probably propose documentation first and start from that, I'm all in favor of sensible default with minimal changes and also a set of defaults for the common cases (i.e. at least going with PGDG repos)

I'm expecting playbooks inside collections to be a very good friend for those purpose.

That sounds like a reasonable plan. Let's TIAS ;)

[MichaelDBA]

The galaxyproject role (https://github.com/galaxyproject/ansible-postgresql) seems to handle PG installation rather flexibly allowing for either PGDG or local repo installations. It has a nice way to customize PG parameters and it never starts or restarts Postgres, only reloads it based on reloadable parameters changing. Perhaps we can make optional the restart option.

Is it OK to copy parts of other ansible work into this one as long as we give the creds to them?

I might add that these options are only available for Debian apt-based distros, not redhat ones. See [https://github.com/galaxyproject/ansible-postgresql/issues/34]

[Andersson007]

Is it OK to copy parts of other ansible work into this one as long as we give the creds to them?

I think it depends on their license (which is different from ours, hard to judge for me as IANAL). We could take some worthwhile ideas from the role but i would avoid copying the code licensed differently.

@tcraxs 's point sounds reasonable. OK, I'm not 100% for or against having basic roles here. IMO:

• we should discuss them one by one before submitting any code
• [like a brainstorming] maybe a separate collection, say community.postgresql_roles? Just a random idea.
• if something implies adding new modules, we should discuss them too prior to submission (idempotency side, etc. I wrote a couple of crappy modules in the past which are not fully idempotent actually - can probably be made though, like postgresql_idx and postgresql_table which look only at an entity's name... BTW we could add an argument called, say, force_idempotency or something to alter a table / rebuild an index based on all argument values)
• roles should be basic, doing one thing blah blah, and i would suggest avoiding using conditions like if this is Debian, do this, if this is CentOS, do that in one file (like, for example, in our setup_postgresql CI role). Instead, i would suggest keeping distro specific things in separate files (one file per distro) and including them in main.yml. Maybe it's not a good idea, i don't know.
• BTW we have Discussions enabled in this repo, so when anyone has a concrete suggestion, feel free to open a dedicated discussion (or use a separate issue).

[Andersson007]

closing this to keep the tracker clean, thanks everyone!