[ikonia]

Summary

added $databases parameter to server.pp to allow iteration from server::database.pp to create databases
reusing the existing included pattern of $roles iterating through server::role.pp to manage roles

Additional Context

Add any additional context about the problem here.
Inability to create database using hiera parameters

Related Issues (if any)

new functionality but could also be considered a fix for #1620

Checklist

• [ x] 🟢 Spec tests.
• [ x] 🟢 Acceptance tests.
• [ x] Manually verified. (For example puppet apply)

[CLAassistant]

All committers have signed the CLA.

[ikonia]

tidied up git config on local machine to stop making commits with incorrect email account associated with GitHub account, merged in with correct email for CLA

[ikonia]

closed by accident

[ikonia]

the other merge requests that where grouped with this change (supporting grant creation, role creation) where merged into the last release, this one was excluded, which pretty much makes the other two pointless, as if you can't create the database, there is nothing to apply grants to

[jst-cyr]

CI test run for this PR: #1689

[jst-cyr]

@ikonia : Thank you for the extra context... I'm going to try to help this moving forward by getting acceptance tests running against a branch PR so we can get some feedback (if necessary) or at least mark as all green before the engineering review.

[jst-cyr]

@ikonia : It seems like testing is blocked right now because of a systemd mismatch on the metadata. There's already a PR submitted #1691 to resolve that so we can move testing forward.

[jst-cyr]

The metadata issue has been corrected and basic spec tests now pass green on this PR.
The acceptance test PR (#1689) was updated and the acceptance tests have been run. Results are here:

• https://github.com/puppetlabs/puppetlabs-postgresql/actions/runs/32032023426/job/95394491873?pr=1689

All 5 failing platforms in this PR's acceptance run (Scientific-7, OracleLinux-7, CentOS-7, Debian-13, SLES-12) match existing failures already happening in the nightly build against main. These aren't caused by your changes. Everything else in the matrix passed.

Compared PR run 32032023426 against nightly run 32032298372.

Next step is engineering review of the changes!

[ikonia]

if it makes things any easier/lighter work, if you review #1694 (comment) that already includes this change (as they are part of a set of changes needed to get full database lifecycle management working) or if you review this change, you've already reviewed part of the change included in #1694 (comment) depending on which way you look at it

[jst-cyr]

Thanks for letting me know that #1694 includes #1661... I've put the two of them together in priority so they get reviewed around the same time by engineering.

Now that #1691 is fixed, I'll run the tests on #1694 as well so we have the acceptance test feedback there too. That way, whichever one the engineering team gets to first will be ready for them.

[jst-cyr]

Rebasing and updating test results on this module.

[jst-cyr]

Running CI tests for this PR via #1710

[jst-cyr]

Acceptance Test Results: https://github.com/puppetlabs/puppetlabs-postgresql/actions/runs/36455591434

All green except for AlmaLinux 8, AlmaLinux 9, and Debian 11. These are provisioning issues also failing in nightly's on main branch, so not introduced in this PR. Latest changes do not conflict with this PR, we're still good from a testing perspective.

[jst-cyr]

Running CI tests for this PR here: #1718

[jst-cyr]

Acceptance Test Results: https://github.com/puppetlabs/puppetlabs-postgresql/actions/runs/38840907664/job/116781163377?pr=1718

Rebased to get latest from main and re-ran. All acceptance tests are green, no provisioning issues! Still good for engineering review.

[SugatD]

Thanks for the contribution @ikonia , and for the context on how this fits with the roles and grants changes. The acceptance run on the rebased head (#1718) passed on all platforms, which is good to see. I have one correctness concern and a couple of smaller requests.

1. Ordering between databases and roles (please fix)

The databases loop runs before the roles loop. postgresql::server::database uses defined(Postgresql::Server::Role[$owner]) to add the role-before-ALTER DATABASE ... OWNER TO dependency. That check depends on parse order, so it returns false here.

With Hiera like:

postgresql::server::databases:
  testdb1:
    owner: dba_test1
postgresql::server::roles:
  dba_test1: {}

the role isn't declared yet when the database is evaluated, so no dependency is added. On a first run, the ALTER can execute before CREATE ROLE and fail with "role does not exist". A second run would converge, so it would show up as flaky, non-idempotent behaviour.

Could you either:

• move the roles loop above the databases loop, or
• add an explicit Postgresql::Server::Role[$owner] -> Postgresql::Server::Database[$name] relationship? This is more robust because it doesn't depend on parse order.

2. Tests

Please add a unit spec in spec/classes/server_spec.rb that checks postgresql::server::database resources are created from databases. Ideally it should include the owner + roles case above so the ordering is covered.

3. Docs

REFERENCE.md has no entry for databases. Please regenerate it with bundle exec rake strings:generate:reference.

Thanks again!