RFC: Align Foreman and Katello

Development RFCs
1

RFC: Align Foreman and Katello

Decision Outcome: November 16, 2026

Context and Problem Statement

Katello has long stood as it’s own Github organization dating back to the days when it was first open sourced and existed as a Rails application that lived beside Foreman.
Since then, Katello has moved to become a plugin of Foreman, aligning on a single installer, tools and conventions in efforts to normalize Katello’s role as a plugin; albeit a large one with bigger dependencies.
The foreman-installer encapsulates this difference, and users feel it, having to think which world do I live in: Foreman or Foreman+Katello.
In that time, Katello usage has grown.
The community has been building a new installer from the ground up with the idea in mind of having a united model desiring to get away from the which world do I live in and rather to have users think in terms of what capabilities, what features do I have enabled.

I think the time has come to finally normalize Katello.

Proposal

There are three major elements:

  1. Move the maintained Katello repositories to theforeman Github organization
  2. Ensure Katello can be enabled on an existing Foreman
  3. Reconsider our baseline Foreman installation

1. Move Git Repositories

Six repositories currently live under the Katello GitHub organization and are proposed for transfer to the theforeman organization. Moving them would place these projects under the intended Foreman organization namespace and make repository ownership and discovery more consistent for contributors and users.

The repositories proposed for transfer are:

  • Katello/hammer-cli-katello
  • Katello/katello
  • Katello/katello-certs-tools
  • Katello/katello-client-bootstrap
  • Katello/katello-host-tools
  • Katello/smart_proxy_container_gateway

2. Ensure Katello can be enabled on an existing Foreman

When a user has installed Foreman using the Foreman scenario in foreman-installer and they want the content management capabilities of Katello, they must re-install their setup from scratch. Katello adds constraints on top of Foreman’s standard model, and does not posses the ability to migrate key data types (such as organizations) to match Katello’s expectations.

This change would be to add the right set of migrations to ensure a user adding Katello properly connects the right set of models with their backend implementations. That any additional restrictions are handled. Any behavior that changes the core model of how a Foreman entity works, is either moved to Foreman core, or relaxed in Katello to arrive at a common model.

This change also requires handling of certificates since a typical Foreman installation relies upon Puppet CA certificate, while Katello has a self-signed certificate chain generated from a different set of tooling. This is handled much more cleanly in foremanctl than foreman-installer and thus this convergence of the two could be handled there instead of applying to foreman-installer.

3. Reconsider our baseline Foreman installation

With the rise in Foreman+Katello installations over the years, with our design of foremanctl to unite into a single model of installation with features that can be added, we should consider changing the baseline from pure Foreman to Foreman + Katello. Which inherently means also foreman-tasks and foreman_remote_execution.
As these establish a broader baseline of capabilities for managing infrastructure, as these all increase the resource requirements necessary from a plain Foreman installation, as there are multiple other plugins that rely on this configuration, making them the baseline means the community can focus on designing around this from the beginning.

Yes, this would be a shift from Foreman’s roots. However, in those 15+ years a lot has changed about how the application is built, how the community uses and deploys. History should be consulted, but ultimately the decision should reflect where the project is at today, where the project is headed tomorrow, and what most benefits users and contributors alike.

Alternative Designs

  • Keep foreman as the baseline, and for anything not in the core repository, it must be thought of as a feature that is added and support that.

Decision Outcome

Pending. No decision has been made yet.

2

to ensure a user adding Katello properly connects the right set of models with their backend implementations

By “models” here do you mean Rails models such as Organization?

The main incompatibility I’m aware of is that in Katello, you cannot nest organizations, e.g. organizations cannot have a parent and are at a single level. (This is in contrast to Locations, which you can nest.) Are there any other examples which will need a migration?

3

big :+1: from me

Again, :+1: from me. This would simplify many users life. We may need to think about feature to hw requirements mapping and warn the user before plugin installation.

The way you wrote it, I’m not sure whether the proposal is to make Katello a dependency or just installed by default with opt-out capability. I think the later but I’d say we should not rule out the former either and consider it.

Based on the last community survey in 2020, we already saw majority (54%) installing Katello. In 2021, we saw 45%. We don’t have more fresh data. I looked at support topics over the last years and selected those where we can tell if they use or don’t use Katello. In 2026 where we could tell, 73% environments had Katello installed (authors deduplicated). In 2025, it was 74%, in 2024 it was 76%. I dare to day, this has become quite common. I think Katello and REX solves a lot of today’s datacenter problems and I think it should become a default experience.

EDIT: since I had the data locally I also asked LLM (GPT 5.6 Luna) to evaluate and it detected even a bit more than the script, 82% for 2026, 83% for 2025. It took more things into consideration (foreman/katello versions pair, workflows specific for katello etc).

Without Katello, foreman-tasks and foreman-remote-execution always being present, they can’t be relied upon in other plugins. This is why provisioning (and few other areas) do not use foreman-tasks for async operations. This is why we never used Pulp for storing and distributing boot files to TFTP proxies. I could find many more examples where this had a negative impact. So I’d be happy to hear what others think about both paths.

4

Yes please. I’ve been thinking about that myself for some time but never had the time (nor access) to get it done.

I think that is great.

Perhaps a middleground: we know of some restrictions (like the nested orgs). Would it make sense to introduce a setting in Foreman to allow nested orgs? We could make it default to off for new installs, which should allow for the migration.

Or are am I too premature about implementation details?

I certainly think it is good to evaluate what Foreman gives you out of the box. Both as a user and as a developer.

We’ve talked for a long time about integrating foreman-tasks into Foreman core. Recently I spoke to @aruzicka about this and I got the impression there a potential different path. Rails 8.1 introduces job continuations and he was asking out loud: with that, do we still need all the complex orchestration that foreman-tasks provides? I really like the idea of relying more on Rails functionality instead of coming up with our own.

Regardless of implementation, I think that integrating the concept of tasks into Foreman core makes the lives of developers easier. Whether that is the current plugin or make all plugins adopt the Rails implementation.

5
  1. Yes please
  2. Yes please
  3. Personally I would prefer having an option to run Foreman without all the extras (pulp, candlepin), but I can see the merit in having the extended feature set available

with my wishful thinking hat on:
If I could add one more, I’d also like to suggest unifying the taxonomy model. Some resources in Foreman are globally available, others can belong to only a subset of organizations and Katello takes the “resources belong to exactly one organization” route. I know this has been discussed ad nauseam in the past, but this would be a nice opportunity.

At the risk of drinking too much kool aid:
Since ActiveJob’s introduction in rails 4ish, it always felt too simplistic to fill our needs. With the introduction of job continuations, I would hope we’d finally get something more sensible than the fire-it-and-forget-it jobs we had up until now.

Some parts of our collective codebases built some very intricate things around dynflow, but it may be a very, very big hammer for others. There are places where we don’t really rely on all the orchestration and instead we spawn many single step execution plans. We also have some ActiveJobs, but those again get shoehorned into Dynflow as single step execution plans. Both of those use cases would be a much better served by “native” ActiveJob, without routing it through Dynflow.

With that out of the way, foreman-tasks could still have its place as a lightweight management console on top what Rails provides.

We could have both living side by side with the same user interface above them.

From the start, foreman-tasks expected there would be other backends apart from Dynflow, but it never really happened. Since our last conversation, I let ai do some happy hacking on it and it seems it would be a reasonable way of transitioning whatever we can to “native” ActiveJob piece by piece.

6

First, thanks for the data @Marek_Hulan !

Yes. And as noted:

I think this is one of the trickier ones as even if we default to it being off we still need an answer to “what happens if a user turns it on or was using this feature before adding Katello”.

@ekohl I noticed you only talked about the developer :slight_smile: Do you have an opinion on the user side?

@aruzicka – just checking, is this as a developer or as a user?

@aruzicka Slightly putting you on the spot here. Do you have an idea already on what that unification should be or do you more simply want to call out that this RFC should capture unification and work out the details later?

7

1: I think it’s a good idea, I don’t see a good reason why to leave them separated
2: While it will be an effort, I think it would be a good idea. We also thought about a “capabilities” model, where Foreman changes according to the available proxies attached to it. We may want to explore this route even more than what’s proposed here.
3: I would argue that we should separate a pure content management concepts and Katello’s content flow (the concepts of environments, content views and promotion). I would vote to add an abstract content management language into foreman as first rate citizen to deal with things like TFTP, proxy/capsule installation media e.t.c. with some default implementation (we can argue that it can be pulp, but I will leave it to a separate discussion) and make Katello content flow opt-in as it is today.

8

Not well fleshed out, but I have submitted a talk for cfgmgmtcamp about the exact topic so I’m following this with great interest.

I think Katello is still very heavy to be deployed out of the box and I really like the model where you start small and add functionality as you need it. But my biggest questions are around longer term use of Foreman and then see how to work our way back to what we want to provide.

This is basically the question where we want to be in 5 years. It’s hard to ignore containerization and we have heard plenty of stories about Foreman deployments shrinking in size because users simply have fewer stateful systems. Large homogeneous deployments are the prime target to deploy in a container platform like Kubernetes, but we’ll likely see a long tail of heterogeneous hosts that have something that is difficult to containerize.

I think there’s tremendous value in having an overview of those hosts. To me that has always been the core feature of Foreman.

Then you need a way to get those hosts in there so some mechanism for that is needed. That is needed for existing hosts, but it’s also nice to support the provisioning of new systems. Again, I still like the whole lifecycle control aspect. Some kind of cleanup is then needed.

But when we get to managing the system, I have bigger uncertainties. Traditionally Katello provided content syncs (RPM, Debian, etc) that systems could consume. For configuration management we have REX, Ansible, and Puppet.

If we look beyond the horizon, where will that go? Red Hat has started bootc which changes updates/upgrades to essentially boot from a new image. In that world I can still see the value in having that inventory, which can report the image. But to do patch management, perhaps Katello would need to integrate with tooling to build images. Note that there are also Containerfiles for Debian and Ubuntu so those could become more broadly supported. Note you can also run validation tools like OpenSCAP on container images.

But do we really want to become a container building tool? Or is there something we can integrate with?

And the (potentially) complex setups that Katello supports with lifecycle environments, is that still relevant in a new world? How many people do more library → test → production?

Because I have so many questions, I started with the parts that I do know: focus on the base level developer experience so that we can build whatever is needed by the real world in a few years. I’d love to remain relevant as a project, rather than that legacy system somewhere in the corner that’s running to support some even older legacy systems.

9
  1. Yes
  2. Yes
  3. Yes.

Additional question to no. 3: Are we still going to support “vanilla” foreman installation, or will we completely abandon it?

A little off-topic to nested taxonomies:

We know of some restrictions (like the nested orgs). Would it make sense to introduce a setting in Foreman to allow nested orgs?

Do we really have to support it? Can’t we migrate to the behavior where taxonomies cannot be nested? It would be great to have data on how many users actually use nested taxonomies.

10

I agree with all points.

The more the merrier. Honestly, if we can simplify our taxonomy even further, I am all for it.

Yes, however, might be wise not to do this all at once, only if it is easier for us to do so.

Sounds too nice to be true.

I remember the first days we were discussing how to approach long running processes and I was the one fighting for a resume functionality. Honestly, after quick look at what job continuations provide, this was exactly what I had on my mind, not Dynflow. But it happened :slight_smile:

Very good point, I am currently designing the Secure Provisioning workflow where the idea is to download netboot.iso to TFTP/HTTPBoot proxy with ideas of generating one netboot.iso per individual host (in case of static IP provisioning) were Katello/Pulp would be ideal storage system for these. One of my concerns today is that we do not want the TFTP folder to grow too much, /var/lib/pulp is already “the place for a lot of content”.

Agreed, perhaps we should flesh out formally where we want to drive Foreman in the next 5 years. Without too much thinking about it, this is my guts feeling what we should focus on:

  • multi-tenant inventory (top-notch UI experience and API consumable by other tools)
  • content provider (including container and OS images as well as promoting workflows)
  • audit (security, compliance, patching)
  • network-based provisioning tool (more streamlined, ready for bootc/image-based OSes)
  • cloud/virtualization provisioning tool (more DIY approach, looking at you OpenTofu plugin)
  • bootstrapping and ad-hoc execution tool (SSH remote execution)

And what I think we should not focus on directly as a primary goal, but integrate with:

  • legacy configuration management (Puppet, Chef, Ansible)
  • provisioning services (DNS/DHCP/TFTP)
  • OS image building (osbuild, image-builder)
  • container building tools (podman, docker, buildah)
  • gitops (CICD pipelines, native API/tools/utils for easy integration)

By not focusing I mean making sure that it is easy for others to integrate Foreman into these environments: Puppet shops, managed provisioning, image building, container building, gitops etc. But not doing the heavy lifting here, not writing new plugins that will allow to do this stuff via Foreman UI/API/CLI.

As an example, building an OS/container image should not be job of Foreman, but we should provide ways to integrate it: ad-hoc CLI, scripts, MCPs or Ansible/Terraform packages.

I think we should no repeat the mistakes we made trying out to write dozens of plugins to do everything, instead, I am thinking about stories where we develop supportive tools for the ecosystem where Foreman can play critical role of the content provider to pull from, to push into and an inventory that uses the content with easy to use provisioning to consume all of that or easy to use way of registering nodes into.

11

Given the majority uses Katello already, majority does not use nested Organizations. Some relevant reading from the past

Last community survey (174 respondents) say that organizations are widely used, this is the count of organizations they have in their systems.

  • 1–4: 74
  • 5–9: 47
  • 10–49: 32
  • 50+: 21

We can’t tell how many of those have nesting, but again, Katello is adopted by majority already.

12

One additional idea - with the power of systemd socket activation, is this really an argument? Does Pulp or Candlepin even activate when there is no RHSM checkin or content synced in foremanctl deployments? I guess during installation we need to setup everything, but after a restart they should not be activated unless user ping them via hammer ping.

13

I would really like to see bootc support moving forward, as it will open us to a bit different market of endpoint machines, not only classic servers as it is today.

I think in this world most of the tasks we consider as configuration management (e.g. package installs, configuration file changes) will be still reusable, but it will be done before image building.
For that, I think we will need to have content storage as a first rate citizen in Foreman.

I think adding Katello as it is today to default Foreman setup makes the entry bar even higher that it already is today, and that’s something that we should strive to reduce. Maybe the middle ground would be to support some sort of a lightweight Katello workflow, which will consume less resources on the machine and will add less knobs and switches to the user.

14

I agree, there is already a lot we support, we just need to run through the finish line. With Katello onboard, we can deliver a full content and provisioning story.

15

So far, this RFC has come to agree on the first two major points. I feel confident locking in the moving of the git repositories.

On point 2, there is agreement on the idea, and differing opinions on how to approach it primarily around taxonomies. To summarize, the two key ideas:

  1. Modify Katello to support nested organizations
  2. Drop nested organization support in Foreman

On point 3, this has sparked some bigger ideas and thinking as I suspected it would. And again, this has a few key points:

  1. The data shows the majority of users already have Katello so we should embrace this as the baseline for deployments.
  2. We should keep plain Foreman as the baseline and users should add functionality that they need. However, that some functionality, or technology should be present in core (e.g. tasks). This should make us ask, how do we define “basic Foreman” ?

As part of this discussion, some folks keep bringing up “basic content” management and splitting that out from Katello. For me, there is not a clear enough argument as to why we should split these two. What the value of this is to the end user, to us as a community.

An element of this part of the discussion should be on balancing complexity and predicability. The more combinations of features that are supported, the more complex the testing and knowledge matrix gets.

The https://theforeman.org/ states:

Foreman is a complete lifecycle management tool for physical and virtual servers.

Perhaps what that means to us should be our baseline.

I generally agree – we should have a better stance on where we try to directly supply features and what areas we provide integration points.

16

For this, how will Katello code contributors transfer over to the theforeman organization? Will we have a Katello team in GitHub that has rights for just the Katello-related repositories? And if so, will the admins of that team have the rights to add more Katello contributors? Or will there be a connection now to the theforeman administrators?

I think it makes sense as long as the Katello-focused contributors can keep maintaining the Katello repos as usual.

I like this idea. When this is started, we’ll need to explore what happens when you run all of Katello’s migrations after all of Foreman’s migrations. Once any issues there are fixed, we could continue on running the same katello-after-foreman migration test as part of the nightly pipeline (and perhaps PRs?).

@Shimon_Shtein your idea here has parallels with RFC: Katello repositories for internal use, so +1 from me. I would like to see basic Pulp functionality drawn out of Katello and put into a lighter plugin. This could reduce the Katello monolith.

@ekohl I believe we’re at a turning point where Katello needs to lean into its container registry or find a strong project to partner with. I’m seeing more and more reports of people using Katello to host container images to assist with on-premise deployments of container-based software. Recent fixes to get OpenShift-related client tooling working with our registries is one sign.

I could see Katello’s content future being largely container-centric and focused around storing container images & the packages that make up those images, alerting about security issues in them, and helping users connect those images to machines, especially bootc ones.

To sum that up, though, this container-focused idea builds nicely on the principals of Katello that are based on historical RPM & Errata management use cases. Katello can change shape while keeping its core principals.

My goal is to push for Foreman 5.3 to include this. I will add that there is a tie now between bootc and Katello since subscription-manager is what knows that the host is a bootc host. Full Bootc integration requiring Katello is another facet to keep in mind when discussing getting Katello and Foreman closer together.

Agree here as well, a massively capable project like Foreman needs some guiding principals that can be constant reminders to keep it from getting convoluted. Hopefully these principals can make it simpler, even.

17

Do you happen to have data about the amount of environments/content views there are at Katello installations?
I think the fact that Katello is installed indicates only the desire to manage content in Foreman, which in my opinion is rational and essential, especially with the embrace of container world. If we want to decide whether we should add simple content management (no subscriptions, no environment flow, just plain store and publish) as opposed to full Katello workflow, we should see a bit more detailed metrics. I think a good metric would be the amount of environments (clear indicator for promotion being used) and maybe content views, but I leave it to more experienced Katello people to define those metrics.

This exact statement is the one to favor splitting content out of Katello.

18

Call it a thought experiment: if Content Views and Environments were hidden from the user would this achieve the same result? If this is about not having to run Candlepin, how big of a deal is that in reality?

I am still failing to hear a good argument for how this simplifies things both for the user and our architecture. That isn’t to say that it’s not, but I believe it requires someone actually building out a fuller design that considers all elements of what Katello provides today and how those would be accounted for.

How?

19

We would normalize it with team(s) like with other plugins and grant the right level of permissions across the needed teams to ensure the current set of Katello maintainers can handle it. I can spell this out more directly in the RFC if it would help?

Why do you feel the Katello monolith is a bad idea? Plugins create context and release overhead, a careful balance is needed. Look to the discussions around pulling code back into core, or to the fact that when we want to change something across the community how many repositories have to be touched. What’s more valuable right now do you think, splitting Katello into pieces or slimming it down by moving “core” elements to Foreman itself? The answer can be both, but I am looking to the order of things.

This got me thinking, is it that content should be pulled out of Katello or that “entitlement” handling should be pulled out? And where to draw the line? subscription-manager for example is both a way to get hosts into inventory and manage the entitlement aspect of the content. How would we get hosts into inventory without Candlepin for RHEL-based systems?

20

Turns out, someone already had this dream and executed on it :slight_smile: