Katello 3.14, deprecate puppet types

deprecate puppet types?


What does it mean, no longer puppet modules in repos and content views in 3.15?


while I’m not involved in this process and so have only second-hand knowledge, looking at the pull request and the Pulp plugin docs it looks like Pulp3 has dropped support for Puppet repositories. That means that Katello no longer has a way to manage those and because of that, yes there will probably be no longer a way to manage Puppet modules through content views in any version that ships with Pulp3.
Maybe someone closer to the development can shed some more light on this?


Also not directly involved, but @areyus is correct. Pulp 3 doesn’t have a plugin and Pulp 2 will be dropped in the future. I’m not aware of any plans to implement this. If this is something you care about, it will need people to step up and implement this. In my experience the Pulp folks are very friendly and helpful.

To clarify, it will actually be the katello 3.17 timeframe (probably 4.0) before its removed.

In addition to pulp3 not supporting it, we’ve found that the vast vast majority of users that are using puppet with foreman/katello prefer other workflows for content management with puppet (such as r2k/git).

Thanks for the clarification. :+1:

I have used both puppet and ansible and by far puppet is superior. Just take the example of nested loops. In ansible each loop has to be a new file which is not only annoying but also harder to manage. What modern lang or DSL has no concept of a for loop? Creating 100% fully parameterized data free code that can handle any number of items that is completely data driven where data updates alone determines what steps or work the code does or does not do is FAR faster, cleaner, and easier in puppet.

Also there is another VERY big reason for puppet over ansible. Puppet HAS an agent. Regardless of the status of the network or the ssh daemon puppet keeps running. I rely of this to do ACTIVE security scanning and remediation. For example puppet manages the passwd and shadow files. If any changes at all (local account creation, etc) are detected puppet triggers mailx to send alert and does a systemctl stop network. Also having an agent is CRITICAL for systems over poor/slow network links because jobs keep running and doing tasks like logging network issues, ensuring services that fail get restarted, etc. Also if a hacker does try to stop puppet we get alerted when the system misses a check-in so we find out about potential hacks VERY fast.

Plus with puppet there is no need to even enable ssh on sensitive DMZ systems GREATLY reducing attack vectors and if we do need ssh it’s just a simple data change and wait for puppet to run again and all of it is CERTIFICATE chain secured. DMZ systems are logged in to via console to turn ssh on only if needed then turned off as the app(s) only need ssl/https ports. Puppet still works in these environments as we change the port it runs on to be 443 on a second IP on the system that is only allowed to talk to it’s local capsule. ALL updates and management is SSL/HTTPS ONLY - NO SSH. Foreman/puppet allows this to be possible. basically ALL ports not absolutely needed for an app to function are BLOCKED including SSH.

Some systems do NOT have sshd running at all and are managed via XRDP based connections like the Linux terminal servers. RDP (xrdp) is used beause it standardizes win and Lin remore access without the risk of misconfiguration allowing someone to crate a back door VPN.

Long story short puppet is just BETTER. To bring ansible on par with puppet it has to be able to be able to at least handle nested for loops AND having an agent and PULL mechanism NOT reliant on ssh that is SSL based is a MUST. Also NO I’m not doing a total hack and cronning local ansible runs.

Hi @rhcev3 and welcome to the community!

Foreman does have support for both Puppet and Ansible - users are free to use whatever solution works better for them. There is no need to argue here about which is better and why, as the Foreman community realizes that each of them have their valid use cases and each organization has its own considerations as to which tools to choose.

What was mentioned in this thread (and elsewhere), is the fact that most puppet users prefer not to use Katello to manage their puppet modules, but rather opt for more native solutions such as r10k.
Due to this fact, and the fact that there is no Puppet provider yet in Pulp 3, Puppet management with Katello will be dropped in Katello 4.0. Other puppet workflows will not be affected by this change.

Since you are quite clearly a major puppet user, you might be interested in the discussion in The Road to Making Puppet Optional which details some changes that are in progress with regards to how Foreman integrates with Puppet for various workflows. You may also be interested in a related talk I recently gave on the subject as part of the Foreman Birthday Party 2020.

1 Like

What worried me to was the inability to upgrad becaus e I loose the incredible power of setting parameters that I can then use it in hiera to drive data driven puppet flows.

What I propose is a video VoIP share session and I can walk through how I make full use of the power of foreman, katello, puppet, etc.

Maybe integration with jfrog artifactory for puppet storage?