bastelfreak: and that's probably a good reason to keep the --no-use-v1-api command line option around for a bit: various READMEs document its use, making it a noop keeps compatibility

yeah

i agree

ewoud: https://github.com/voxpupuli/librarian-puppet/pull/104

I'm planning ahead after just patching saz for something already fixed in puppet namespace. EL = RHEL+ALMA+...

It would need to be in place before 10 - Its more the general point is there any mechanism to use <old>-<module> for OSn and <new>-<module> for OSn+1. Perhaps you can influence the PUPPET_LIBRARY_PATH (?) based on agent facts. Distinct puppet servers would work of course.

you cannot have two modules with the same name in the same environment

frisbee[m], doesn't that ask for an entry in the "base" role you have?

so you need two environments or two puppetservers

but again, why support both?

migrate to ours and be happy?

ah, yeah, same name won't work, sorry

Morning!

morning

o/

@bastelfreak Thanks for the approval on that ldapquery module. I'll get a release PR prepped.

\o/

Then afterwards, I'm going to go to town on the configuration stuff.

It seems really odd at the moment.

it's ldap? :D

It's the way it conflates these puppet settings I don't like. https://www.puppet.com/docs/puppet/5.5/configuration.html#ldapbase

I'm not even sure what else they're used for anymore.

The LDAP ENC was removed in Puppet 6, but these remain.

I did not know that

from a quick grep it looks like https://github.com/puppetlabs/puppet/blob/ad7d75b08dfff5e308fde199407d84308d74e538/lib/puppet/util/ldap/manager.rb#L24 still uses it

2015 was the only team I met a person that used the LDAP ENC

*only time

though I question if that class itself is actually used

This still exists https://github.com/puppetlabs/puppet/blob/ad7d75b08dfff5e308fde199407d84308d74e538/lib/puppet/provider/ldap.rb but I don't know what uses it.

bastelfreak: only team also works :P