Change default postgres version to 14

[jonathannewman]

Postgres 11 is no longer supported as an installation method from Postgres.org. As a result, installations will fail using puppetlabs-postgresql with failures like:

   Error: /Stage[main]/Postgresql::Server::Install/Package[postgresql-server]/ensure: change from 'purged' to 'present' failed: Execution of '/usr/bin/yum -d 0 -e 0 -y install postgresql11-server' returned 1: One of the configured repositories failed (PostgreSQL 11 7 - x86_64),
     and yum doesn't have enough cached data to continue. At this point the only
     safe thing yum can do is fail. There are a few ways to work "fix" this:

         1. Contact the upstream for the repository and get them to fix the problem.

         2. Reconfigure the baseurl/etc. for the repository, to point to a working
            upstream. This is most often useful if you are using a newer
            distribution release than is supported by the repository (and the
            packages for the previous distribution release still work).

         3. Disable the repository, so yum won't use it by default. Yum will then
            just ignore the repository until you permanently enable it again or use
            --enablerepo for temporary usage:

                yum-config-manager --disable yum.postgresql.org

         4. Configure the failing repository to be skipped, if it is unavailable.
            Note that yum will try to contact the repo. when it runs most commands,
            so will have to try and fail each time (and thus. yum will be be much
            slower). If it is a very temporary problem though, this is often a nice
            compromise:

                yum-config-manager --save --setopt=yum.postgresql.org.skip_if_unavailable=true

    failure: repodata/repomd.xml from yum.postgresql.org: [Errno 256] No more mirrors to try.
    https://download.postgresql.org/pub/repos/yum/11/redhat/rhel-7-x86_64/repodata/repomd.xml: [Errno 14] HTTPS Error 404 - Not Found

To make matters more complicated, puppetlabs-postgresql is impacted by https://yum.postgresql.org/news/pgdg-rpm-repo-gpg-key-update/

see puppetlabs/puppetlabs-postgresql#1565

so this too will not work until a new version of that is released with a fix.

[smortex]

My guess is that not passing an explicit version by default and letting the puppetlabs-postgresql module default to be used would be more portable. Unfortunately, this module is currently so broken testing anything require way more efforts that I can afford 😒

The fact that the module manage PostgreSQL by default is a bad practice IMHO. ATM, my recommendation for integrating PuppetDB in a control repo would be to have a puppetdb profile like this (have a dedicated PostgreSQL / firewall profile, disable firewall and dbserver, and use whatever settings you want):

class profile::puppetdb {
  include profile::postgresql

  class { 'puppetdb':
    manage_firewall  => false,
    manage_dbserver  => false,
    node_ttl         => '0d',
    node_purge_ttl   => '0d',
  }

  class { 'puppetdb::master::config':
    manage_report_processor => true,
    enable_reports          => true,
  }
}

[bastelfreak]

this module is currently so broken testing anything require way more efforts that I can afford

I feel so the same. And the lacking CI pipeline is really a problem for me when I review PRs. I suggest to wait for #378 until we merge anything here.

[jonathannewman]

I can understand that perspective. An alternative one is that updating the value doesn't make things worse than they already are and will make it functional. the "11" value is known to not work and that "14" does. The application has specific expectations about the version of Postgres used and 8.x expects 14. Updating the value doesn't make things worse than they already are.

[bastelfreak]

@jonathannewman stupid question, will this upgrade existing installations from 11 or whatever to 14? We should reflect this properly in the CHANGELOG.md

[jonathannewman]

Yeah good point.

[nabertrand]

Having the official puppetdb module be broken is not a good look for Puppet. Also, why aren't Issues enabled on this repo? Is there a different way for users to report issues?

[binford2k]

Issues should be enabled, so I turned them back on.

Per the Jan 9 Vox sync, PMs for our Content and PE teams are looking at the module and discussing alternatives. We'll have more info at the next sync.

[corporate-gadfly]

Since PostgreSQL 11 repos have been moved to archived yum repos, I have to tell puppetdb and postgresql to not manage the yum repos.

My workaround is to use:

postgresql::globals::manage_package_repo: false
puppetdb::manage_package_repo: false

And then manually set enabled=0 in yum.postgresql.org.repo and create a new pgdg-11.repo pointing to baseurl=https://yum-archive.postgresql.org/11/redhat/rhel-8-x86_64.

Hope that helps someone.

[bastelfreak]

@jonathannewman can you please also unpin the postgresql module in.fixtures.yml and ensure the metadata.json allows the latest major version?

[jonathannewman]

@jonathannewman can you please also unpin the postgresql module in.fixtures.yml and ensure the metadata.json allows the latest major version?

Yep. Done.

[jonathannewman]

I'm not planning on resolving all those new spec issues. They existed prior to my PR, and I frankly don't have any more time to devote to this.

[bastelfreak]

@jonathannewman that's not correct. We fixed the pipeline and it passes on master. Right now it complains about an outdated REFERENCE.md, because you adjusted the puppet-strings documentation but didn't regenerate it. you can do it by running:
bundle exec rake strings:generate:reference