TL:DR Support Puppet 5, 6, 7 on clients is going to be dropped altogether and support for Puppet 8 is going to be replaced with OpenVox 8. The text mostly deals with when and how.
If you still want to hear more, read on.
Our provisioning templates accumulated a lot of puppet-related cruft over the years. Up until today, we even had code paths that dealt with setting up Puppet 5 (eol since 2021). At the same time, OpenVox support is still only partial even though a PR filling at least some of those gaps has been opened since January this year.
I’d like to take this opportunity to kill two birds with one stone and do a bigger-ish cleanup. The cleanup would roughly amount to:
An argument could be made that as of today there is no such thing as open source puppet anymore and there is no need to carry code to set it up on hosts. So the question really isn’t if we should drop it, but rather when we will drop it.
The approach outlined above would allow us to do things incrementally as well as give people some breathing space, release-wise I’d aim for steps 1-6 being done for Foreman 5.1 with final Puppet drop going in for 5.2 to provide one last transitionary release.
If we went with the other option, everything would probably collapse to one or two bigger-ish PRs, but at the same time it would save us from doing some work which would be eventually dropped anyway. The switch would then happen in a single release, most likely in 5.1.
As of now, @jakduch is spearheading the cleanup (thank you) with P5 cleanup being merged already and PRs being opened for P6 and P7.
I’ll slowly continue with merging PRs the incremental way, we can switch to the other approach at any time if needed (or deemed better by the broader group).
@bastelfreak I know there was some discussion about future OpenVox packaging going back to more integrated packages instead of AIO ones. I did not follow this to the end, but you very likely know if there is already a decision in one or the other direction. I want to avoid more work when we drop this and have to re-introduce it later.
You can also see if using puppet config as a command to change configs is better. It could also print the config file location. May not always work, but today we do too much.
Note that with a plain empty puppet.conf it can work. You only need to write down the values you really care about (point at the right server, with the right CA, possibly set the right hostname instead of autodetection).
Disclaimer - I’m involved in the VoxPupuli community and author of PR #10816
I’d take the opportunity to also discuss how should OpenVox support be implemented in templates.
Currently:
there is a snippet, openvox_repo, to enable relevant repositories with versioned parameters, enable-openvox9-repo and enable-openvox8-repo, it’s in (almost) all the templates
the puppet_setup snippet defaults to OpenVox on some platforms (not all), controlled by two versioned parameters (enable-openvox8 and enable-openvox9) that effectively make the same changes. No difference between the two.
Package manager signatures are imported by puppet_setup
What do we want?
Enabling by default if a Puppet Server is defined, with a force-openvox to install the client when there isn’t one?
Replace enable-openvox8 and enable-openvox9 with a generic enable-openvox used to install OpenVox agent - nothing gets installed by default even if a Puppet Server is defined?
Something else?
Various things:
Puppet changed terminology even before OpenVox birth - there are no masters anymore, but Puppet/OpenVox servers. Might as well update it in Foreman too.
puppet_setup snippet tests were non-existent before #10816, now only cover openvox-related parameters. Should they be expanded to cover the rest of the snippet? (I guess yes)
This might be an occasion to start improving snippets/templates docs/comments
I think in the past we just ran the equivalent of dnf install puppet and I’d expect the equivalent for OpenVox to be the default. Remember that openvox-agent and openvox-server have the proper metadata (for RPM Provides: ...) so ensuring puppet-agent is installed should still work.
I don’t see the need for a generic enable-openvox. Can you elaborate what the semantics of it would be?
My view is that we should:
Drop all code (parameters, repo setup) for Perforce Puppet - it’s dead and unmaintained, without a way to test the closed stuff.
Support parameters to enable the OpenVox repositories directly, for users without Katello
When a Puppet server is configured in Foreman, install the puppet-agent package and configure it assuming AIO file paths
Idk, for now it’s coherent with parameters previously used with Puppet
If, for some reason (like hw provisioned through Foreman and then pointed to an external Puppet/OpenVox Server), the user wants to install the OpenVox agent even if there is not a Puppet server defined/installed in Foreman
That’s already a WIP if I understand correctly
Done, it was the main reason for #10816: OpenVox repositories are enabled if enable-openvox9-repo or enable-openvox8-repoare true. No checks about Katello.
