RFC: Containerized Foreman & Provisioning Infrastructure

Development RFCs
, ,
1

RFC: Containerized Foreman & Provisioning Infrastructure

Feedback Due Date: 9th July 2026 (One month from publication)

Context and Problem Statement

Background

To enable provisioning workflows, the foreman-installer currently manages the configuration inside the Smart Proxy and (optionally, but enabled by default) the DHCP, DNS, and TFTP services. The Smart Proxy then communicates directly with these services on the host.

With containerization, our services run in containers. This prevents Smart Proxy containers from managing host-level infrastructure, preserving isolation and avoiding complex mapping requirements.

What is the problem being solved?

As part of our broader initiative to transition Foreman production installations from the traditional package-and-Puppet approach (foreman-installer) to a modern containerized model using Podman quadlets and foremanctl, we have reached an important architectural crossroads: how we handle provisioning infrastructure.

Historically, foreman-installer didnā€™t just install Foreman; it acted as an infrastructure orchestrator. With its CLI flags, it would install, configure, and fully manage host-level daemons such as ISC DHCP, BIND (DNS), and TFTP. We need to define a clean, sustainable model for how containerized Foreman interacts with provisioning infrastructure.

How does this affect the users?

For Users

Users are now responsible for providing, deploying, and managing their own provisioning infrastructure. This includes configuring DHCP, DNS, and TFTP services independently. Foreman and its Smart Proxies will focus solely on communicating with these user-managed external services via established APIs and protocols.

For Admins

Upgrading or patching Foreman will no longer pose a risk to the availability of core network infrastructure. Because DHCP, DNS, and TFTP are decoupled from the application lifecycle, administrators can perform Foreman maintenance windows without inadvertently disrupting active network assignment or service state. It was always limited in options, so as you scale youā€™d run into blockers.

For Developers

This removes an immense maintenance burden from the core team. We no longer need to maintain complex Puppet installer modules to manage underlying operating system daemons, troubleshoot package conflicts, or handle edge-case configuration files for network services we donā€™t own. It allows us to focus entirely on making foremanctl an exceptional application lifecycle manager.

Technical objectives

  • Decouple the deployment and lifecycle of network infrastructure services (DHCP, DNS, TFTP) from the deployment of Foreman and Smart Proxy application containers.
  • Standardize Smart Proxy interactions with external infrastructure services via clean, well-defined network APIs or isolated shared-volume boundaries (e.g., a shared directory for TFTP).
  • Support the current list of provisioning methods.

Non-goals

  • We are not deprecating bare-metal or VM provisioning. Provisioning remains a core, first-class feature of the Foreman ecosystem.
  • DHCP - Kea DHCP as main provider, communication via its API. Managed by the user.
  • We are not building an infrastructure orchestrator or a custom DHCP/DNS server inside foremanctl.

Proposal

foremanctl removes any responsibility for installing, configuring, or managing underlying daemons for TFTP, DNS, and DHCP. Users are solely responsible for their provisioning infrastructure.

  • foremanctl will deploy only Foreman, Smart Proxy, database, and plugins using Podman Quadlets. Its role is limited to these services.
  • It is the userā€™s responsibility to deploy and maintain the DHCP, DNS, and TFTP endpoints required for provisioning. The user must ensure that these services are available and correctly configured so that Foreman and Smart Proxy can communicate with them.
  • The Smart Proxy communicates with external DHCP and DNS services over the network, using their native protocols (OMAPI for ISC DHCP, RFC 2136 nsupdate for BIND, HTTP APIs for infoblox/bluecat).
  • For TFTP, the Smart Proxy container requires a volume mount to the TFTP root directory. Users must configure their TFTP daemon to use this shared directory.
  • We are phasing out support for the legacy ISC DHCP daemon and standardizing on ISC Kea DHCP as our preferred open-source DHCP provider.

Technical and project-level impacts

  • Code Simplification: Massive reduction in the complexity of foremanctl and the complete removal of legacy Puppet installer logic that dealt with host-level package management for network infrastructure.
  • Documentation Shift: Our installation documentation will transition from ā€œRun this single massive command to get a complete PXE networkā€ to ā€œHere is how to connect your containerized Foreman instance to your networking infrastructure, along with reference templates to spin them up if you need them.ā€
  • Testing Infrastructure: Our internal CI/CD pipelines will need to be updated to deploy independent network service containers alongside our foremanctl test suites to validate provisioning workflows.ā€‹

Alternative Designs

Provide an Ansible playbook to deploy the managed services with basic configuration. This playbook would be community-maintained and not part of the supported installation workflow.

Example PR: https://github.com/theforeman/foremanctl/pull/532

Call for feedback!

This is one of the biggest architectural evolutions weā€™ve proposed in a long time, and we definitely want to make sure we arenā€™t pulling the rug out from under your existing setups. Since this fundamentally changes how the network plumbing of your provisioning environment works, your real-world insights are incredibly valuable to us.

  • Are you already running Kea DHCP in production, or are you still holding onto legacy ISC DHCP?
  • How can we make the migration from the traditional Puppet installer to foremanctl as painless as possible for your team?
  • Is there anything you are worried about?
  • Any suggestions, things we might have missedā€¦?

Please drop your thoughts, concerns, or edge cases in the replies below. Thank you!

1 Like
2

At customers I had to deal with many different solutions, where I was free to implement a new one for Foreman Kea was not an option yet and ISC DHCP has the nice integration in the installer, so ISC DHCP was it yet. I hope for Kea being supported in the same way and replace ISC DHCP.

As a side note in our internal DNS and DHCP training I switched from ISC DHCP to Kea already in 2022.

In other threads I did only see three flavors foreman, katello, foreman-proxy-content. I think if we end with only those this could be the same conceptional error we faced in the past that Red Hat expects every Smart Proxy to be also responsible for content, but I quite often need just a Smart Proxy talking to DNS, DHCP, TFTP in various ways and this is not only the case if the central system is Foreman and not Katello. So making this easier than using foreman-proxy-content and disabling content would be a good step.

Also we have probably used every Foreman and Smart Proxy plugin somewhere at a customer, so if something is not supported any longer or breaks it will hit us somewhere. This is the disadvantage of not having a fixed set with one name, but using all the tools to solve customer needs! :laughing:

If functionality is dropped like no longer managing the managed service, it adds complexity to the installation process instead of reducing it. Nothing we can not handle with some Ansible playbooks ourself, but if we can get those examples at least collected somewhere under the projects namespace it would allow more collaboration and hopefully improve it.

Currently foreman-installer with --noop and --dont-save-answers is a great way to convince a customer we can do the integration of a managed service with the Smart Proxy without breaking things, so having something similar could be helpful. Of course only if this is covered by foremanctl, if not we are back to Ansible and the options it offers.

3

I did a containerized foremanctl deploy install today to see what the future holdsā€¦ and I found this post trying to figure out how to provision to bare metal (weā€™re using ā€“foreman-proxy-tftp true on our puppet-based installs).

I also tried digging around in the foremanctl repo, and the only occurrence of ā€˜tftpā€™ is from a doc page that seems like the tftp options were copied over from the puppet installer. So it seems foremanctl doesnā€™t support TFTP at all.

I also see no mention of tftp in the containerized documentation here:

Does this mean that currently, thereā€™s no documented way to provision with TFTP on the containerized install of 3.19?

Is there another non-TFTP method we should be moving to instead for bare-metal?

4

Yes,
Provisioning is still in the development phase (TFTP feature by stejskalleos Ā· Pull Request #533 Ā· theforeman/foremanctl Ā· GitHub)

1 Like
5

Thatā€™s the plan for the EL10 upgrade, where Kea is the default DHCP provider.

So making this easier than using foreman-proxy-content and disabling content would be a good step.

cc @arvind4501, heā€™s investigating the external capsule workflow for foremanctl

Nothing we can not handle with some Ansible playbooks ourself, but if we can get those examples at least collected somewhere under the projects namespace it would allow more collaboration and hopefully improve it

Noted.

1 Like
6

In other threads I did only see three flavors foreman, katello, foreman-proxy-content. I think if we end with only those this could be the same conceptional error we faced in the past that Red Hat expects every Smart Proxy to be also responsible for content, but I quite often need just a Smart Proxy talking to DNS, DHCP, TFTP in various ways and this is not only the case if the central system is Foreman and not Katello. So making this easier than using foreman-proxy-content and disabling content would be a good step.

In foreman-installer we had a way to install proxy without content with kind of a non scenario based way(Installing a Smart Proxy Server nightly on Enterprise Linux), I had already thought about having proxy without content in foremanctl and would like to include that as a flavor in foremanctl

2 Likes
7

Hello,

Iā€™m very interested in this topic. My use case strongly relies on being able to easily build, tear down, and keep environments clean, and containers seem like the best way to achieve that.

However, while reviewing the Quickstart for version 3.19, I noticed that the container-based approach that existed around 3.16 is no longer mentioned.

Has support for this deployment method been dropped, or is it simply no longer maintained/documented?

I would be very interested to understand the current direction regarding container-based installations (e.g., Podman/Docker), especially in the context of this RFC.

Regards,
Tux95

8

Hello,
Seems there are another guide here, not tested currently who did ?

Regards,
Tux95

9

Previously we included a note about containerized builds in our regular docs, but weā€™ve spun it out to its own complete set of documentation. If you go to https://docs.theforeman.org/ youā€™ll see Foreman documentation: Foreman with Katello (containerized). This list is shorter than what we have for other guides, but weā€™re working on that. This RFC should result in the provisioning related parts being there.

1 Like
10

I very much appreciate the response - I will review your link and see if there is any way I can contribute.

That said - I wish I would have phrased my question differently, so here it goes:

Is it currently possible to provision to bare metal via the containerized foreman/katello (possibly a non-TFTP method)?