Discovery image based on CentOS 8


In order to use the discovery image to discover new hardware (like the HP Z2 sff G5 and other latest hardware), kernel drivers available in CentOS 8 are necessary (for example the support of the Intel network cards). The latest stable discovery image (based on CentOS 7) is unable to detect the network card which makes returning the gathered facts to the Foreman server rather difficult.

I’ve tried to use the nightly build discovery image without success. It seems the status of the master branch of the discovery image in github is also not working (tried building the image which is possible). Are there plans to update the Discovery image using CentOS 8?

Kind regards,

Ben ter Haar


we did not want to rush this in because maintaining two versions of FDI is twice as much work and having an older version of discovery is safer when you want to install newer version of OS. With EL8 based FDI kexecing into EL7 kernel could not be even possible, I haven’t tried.

But the main reason is that FDI has smart-proxy and it is not yet available for EL8, So actually to be able to ship FDI on EL8, we need to have Foreman on EL8, which is not available yet. Going forward, I’d like to actually remove smart-proxy from FDI and replace it with a simple python/shell script doing the same (kexec or reboot REST API). After this is done, we can start working on this.

Also note EL8 uses new building infrastructure as well (lorax instead of livecd-creator), there might be bigger changes needed in order to build it. I haven’t looked into this yet.

If you want to help with this, we can coordinate works and I should be able to help you. My TODO is currently:

  • Write a replacement of SPDI plugin in something that has no dependencies (e.g. C, golang, bash -ehm- or system-python which is always present on RH systems)
  • Drop smart-proxy from FDI and deprecate the SPDI plugin
  • Build Facter4 for EL8 and get that published in Foreman (client?) repos
  • Build FDI on EL8
  • Bonus: Replace the TUI written in Ruby-newt with whiptail/shell
  • Bonus: Replace Facter4 with uFacter and completely remove Ruby from the image
  • Bonus: Integrate discovered nodes with Remote Execution so users can schedule SSH scripts on discovered nodes


Given the latest developments on the CentOS front (article), perhaps focussing on CentOS as a future platform might be worth discussing/re-evaluating.

I did not know how the discovery image was constructed (in terms of utilizing a smart proxy etc.). That will require a lot of rework to create a solution without these dependencies. I’m not a programmer but I can ask around if help can be provided.


why? the smart proxy is significantly smaller then running foreman on el8? I would expect this not to be a huge task? (at least a build for core / discovery)?

alternatively… can’t we use a el7 smart proxy in a container ? sounds a lot simple then the list you suggested… granted, not everything will work out of the box (e.g. the TUI), but i would argue that is not the majority of users…

We have Foreman and Proxy on EL8 since 2.1.

I think the main motivation for the smart-proxy drop from EL8 is, we need to package the whole ruby stack. That caused several issues in the past, mainly SCL vs nonSCL ruby, since proxy didn’t use SCL before now it does. Facter used system ruby. If we use proxy only for “foreman can reboot FDI” and “Foreman says refresh facts”, it does not really make sense. We could simply replace this with remote execution and do it through SSH. Facts from FDI are not even proxied through this smart-proxy it if I’m not mistaken.

Let me answer to all of you, thanks for comments!

As the current maintainer of FDI, I’d learned over the past years that building and giving support for the current design is difficult. I want to shift from running multiple stacks and components on the image (smart-proxy, discovery service, network configuration and download services and TUI) to more simple approach when discovered node would simply register and bootstrap SSH channel with Foreman. All the rest (reboot, kexec, upgrade firmware) would be done via Remote Execution plugin. That’s the ultimate goal I would like to achieve at some point.

Debugging FDI is difficult, fixing bugs or development and rebuilding takes a lot of time. If there was just a minimum set of features (configure network, simple TUI for PXE-less, register and establish SSH keys) we would not need to update FDI that often.

There is a reason why FDI is based off CentOS, that is RHEL hardware certification. If a hardware is guranteed to work in RHEL, it will likely work on CentOS too. By the way, not much is really changing with CentOS Stream for majority of users, it was just poorly communicated. But this is not the right place for this discussion, if we simplify FDI enough, you can more easily build your very own FDI.

Also, if you compare size of FDI for the last 5 years, it has grown by about 200% because more and more firmware and drivers are added into RHEL kernel. We need to bring it back to reasonable size and I was trying hard to do this by removing some unwanted files (or drivers). The less software and dependencies we have, the better.

Good, I can bump this in my TODO a bit higher.

That does not mean I am starting next week tho, to clarify false expectations.