The problem
The current registration state works very well for users with Katello & subscription manager, EL, or Debian, it doesn’t matter.
For other users, let’s say with vanilla Foreman, the registration is not that great. Mainly for the reason that we don’t have a way how to get facts from the host (= no subscription-manager).
Because of that users have to before the registration create the OS in Foreman manually, then they have to select it in the form and only after that, they can register the machine.
Solution
Create a Foreman mini facter, that will collect only the necessary data required for host creation: hostname, IP, OS details (name, version, family …), and that’s it.
It could be a Python script (2.7 compatible), distributed as a Foreman snippet, that would collect these facts and send them back to Foreman, in the same format as subscription-manager facts does.
This would have multiple advantages:
We can remove all the stuff around the OS hassle
We simplify the process
Being it simple script and a template = easy for community contribution
We already have Python at multiple places, so it’s not adding much complexity
Some notes
I was thinking of doing it in bash, but then I quickly decided that I didn’t want to go that way. It’s out of my abilities and sanity.
The other day I was playing with host registration and noticed I need to specify the OS, which I thought was redundant. So I was thinking about uploading the os-release file to provide facts, which Foreman could parse. Now you mention it, you’ll miss things like hostname and networking details.
The benefit is that you can compile go to a single binary and drop it to a system. While I really like Python, it will be harder to run in practice. Ansible does it, but it’s complex. Plus, you already have a largely complete implementation that produces facts in a format our existing parser can already handle. I’ll note that I haven’t looked at the implementation.
I suggest to design such thing in a way it can be executed via %pre section of Anaconda kickstart. This way, Foreman discovery could be replaced by simply Anaconda (netboot ISO). As far as I know there is Python 3 and some basic tools like dmidecode etc. Just enough to do what Foreman needs to know for discovery, not sure how much you need for registration workflow.
I actually do something like this in my other pet project, tho it is not facter-compatible:
We could drop maintaining a dedicated LiveCD just to do the registration, I think it is unnecessary work. There is one feature called PXE-less discovery which should be straight-up dropped as it uses kexec which turned out to be pretty unstable for booting into OS installers. It is a technology that was not meant to do that, kexec is more for debugging on intel platforms (does support full reboots on IBM POWER platforms but that is a different story).
Lukas what would be the solution for non-PXE discovery?
Years ago, I actually used to have my own homegrown discovery-like solution that just used anaconda, which pulled down an inital ks file via URL< with a wait loop in the %pre.
It would keep running the loop in the %pre, and periodically checking another URL for its final kickstart instructions and providing a few things as parms in its GET like the macaddr, interface name list, list of disk devices etc.
Our sysadmins would then go to a homegrown website which listed all the systems which had checked in, and they would fill in the final instructions (hostname/IP etc) on a page on the weberver and save that record to a local database.
Then, the client would receive its final kickstart instructions the next time it polled the webserver URL, and it would save the rest of the kickstart it received as a file in /tmp that would be used via the %included after the %pre section.
I basically created almost the same behavior and workflow as the discovery process we use today in Foreman, just using anaconda. It worked great for us for many years at a Fortune 50.
The problem is anaconda, is a Fedroa/RHEL family only solution, and I am not sure that could replace all of Discovery.
Interesting idea. So the Foreman could use the script not just for registering existing hosts, but also for hosts that are provisioned. That’s something which could fit the scope.
Just enough to do what Foreman needs to know for discovery, not sure how much you need for registration workflow.
Hostname, IP address (+ networking info), OS details (name, family, major_v, minor_v), that’s all.
We would love to see your implementation and integrate it into Foreman, if that is possible.
Yeah, the idea is to have Discovery to be based off Fedora for all other Foreman users, even those who do not provision Fedora or Red Hat systems with it. Discovery’s job is only to boot up and gather some basic facts.
In fact, if the workflow will be simplified enough and shrinks down to just one or two python scripts, then it should be super easy to create different discovery image kinds based on other OSes. The very first discovery image was actually based on Tiny Core Linux. Whatever works is fine, the discovery image git repository could turn into just one python file + build scripts to build various flavours.
For obvious reasons, Red Hat folks will choose to fully test and support one kind, that would be Fedora flavour.
Edit: I abandoned the go-facter honestly, it is not a good fit for Anaconda-based solution as we need to work with what is present in Anaconda image, there is Python, Perl and lots of CLI tools. Downloading binaries over insecure network is not a viable option.
