See the

puppetlabs-postgresql

module at https://forge.puppet.com/puppetlabs/postgresql?src=slack&channel=voxpupuli

and you really want to use EPP instead of ERB if you're going to use Sensitive since it has automatic wrapping

Looking at release notes and with my own testing, I see Deferred is better - still not sure it can actually handle things with Type Aliases, going to test that next.

But Sensitive... still not seamless enough, though unwrap taking a block was a nice improvement

EPP over ERB has other benefits too, like not forking a new process for each and every template. And you can defer inline_epp

I think I was thinking of https://puppet.com/blog/updating-puppet-modules-for-deferred-functions/ and specifically the returned type introspecting thing that allows you to defer functions in lots of usecases where before it'd have been impossible.

I think there is work being done or designed in the whole area of Sensitive and encryption etc. though. @binford2k might be able to fill you in on more details of what might be coming up.

Passing a Sensitive[String] to a param expecting a String still causes a type mismatch evaluation error, which means I can't use vault_lookup with forge modules without a lot of extra hoops to jump through and calls to unwrap, which kinda defeats the purpose

This is the same problem I faced back when I tried to use Vault with early Puppet 6

So the vault bit might now be solved in recent Puppet 7.

I'm testing on a latest release of puppet 7

Hullo so I went through following images on azure MicrosoftWindowsDesktopwindows10previewwin10-22h2-pro:latest MicrosoftWindowsDesktopwindows11previewwin11-22h2-pro:latest MicrosoftWindowsServerWindowsServer2019-datacenter-smalldisk:latest MicrosoftWindowsServerWindowsServer2022-datacenter-smalldisk:latest MicrosoftWindowsServerWindowsServer2022-datacenter-core-smalldisk:latest MicrosoftWindowsServerWindowsServer2019-datacenter-core-smalldisk:latest and produced https://github.com/voxpupuli/facterdb/compare/master...davidsandilands:facterdb:windows-update Is there anything I need to strip out or generalise? Such as azure based facts?

Hullo so I went through following images on azure MicrosoftWindowsDesktopwindows10previewwin10-22h2-pro:latest MicrosoftWindowsDesktopwindows11previewwin11-22h2-pro:latest MicrosoftWindowsServerWindowsServer2019-datacenter-smalldisk:latest MicrosoftWindowsServerWindowsServer2022-datacenter-smalldisk:latest MicrosoftWindowsServerWindowsServer2022-datacenter-core-smalldisk:latest MicrosoftWindowsServerWindowsServer2019-datacenter-core-smalldisk:latest and produced https://github.com/voxpupuli/facterdb/compare/master...davidsandilands:facterdb:windows-update Is there anything I need to strip out or generalise? Such as azure based facts?

o/

good question

I think it's a good idea to purge

az_metadata

because it's not windows specific but azure specific

in terms of hostnames ip etc do we do anything to generalise or is that just left to default facts and setting anything you want in particular in rspec?

there are some unit tests that enforce foo.example.com I think

I'll sort that, removed cloud and azure_metadata facts

changed all domain to example.com and hostname to be foo (and combo to be both). If that looks sane I'll raise a PR

sounds good

just open the PR, tests will tell us if it's fine 😄

airplane sweat

has faith in the tests

faw

tiny MR - https://github.com/voxpupuli/puppet-cvmfs/pull/156 want the CentOS 9 accept test before I change the repos.

frisbee, like this? :)

(or will my suggestion actually be wrong as you say "change the repos")