Now that Foreman 5.0 has a release candidate, this is the place to provide your feedback. Whether it’s (possible) bugs, thoughts, the interface, or workflow. If you’re sure it’s a bug, a new Redmine issue can also be used.
I have tried the new foremanctl workflow and so far I really like it. FWIW I think that I will be ready to migrate when 5.0 formally releases. I did run into these difficulties:
-
The currently packaged foremanctl package (2.3.0) wants to install foreman 3.19, which is surprising in a 5.0 release. To get 5.0, it requires going to a COPR repo, and it’s still fairly easy to get nightly images by mistake). It seems there are structural differences between the 3.19 deployments in terms of postgres version and redis→valkey and possibly role structural things. It would be really nice if foremanctl were a bit easier to customize at runtime in this way). I did a separate post about this, and it was confirmed that a 3.x version of the foremanctl RPM will ship that can deploy 5.x.
-
The currently released foreman-ansible-modules does not include the cacert parameter to the LDAP auth source module, which is usually required because of CA trust mechanics. I’m hoping there will be a 5.12 release of FAM prior to release.
There are likely to be some edge cases, like enabling apache status, that foremanctl doesn’t currently cover, and can. (I use it to enable metrics.)
Otherwise, the mapping for how to enable features and deploy is pleasantly straightforward. The move to containers solves a lot of the old issues with EPEL conflicts.
Are there plans to switch to openvox/openfact in Foreman 5.0?
@ehelms Would you know an answer to this?
Or to rephrase: what Does the OpenVoxProject need to do so you switch to it in the 5.0.0 release? ![]()
I thought we switched mostly. For the provisioning templates @aruzicka is reviewing those, like Fixes 38993: add OpenVox repository by d1nuc0m · Pull Request #10816 · theforeman/foreman · GitHub.
IMO missing:
- merge Fixes #38946 - Update to FacterDB 3.x by evgeni · Pull Request #11118 · theforeman/foreman · GitHub
- switch from facter to openfact (I can make a PR once #11118 is merged)
- switch Foreman :: Quickstart to the openvox repos instead of puppet.com
This is only for tests, doesn’t fundamentally change the runtime.
What is needed? Are there facts that need to be parsed that are different?
That’s fair. We have switched over Quick start guide for Foreman on Enterprise Linux but haven’t quite migrated all the way. A PR to theforeman.org/_includes/manuals/nightly/2.1_quickstart_installation.md at gh-pages · theforeman/theforeman.org · GitHub is very welcome.
Correct: Use 5.0 containers by arvind4501 · Pull Request #753 · theforeman/foremanctl · GitHub is in Release 3.0.0 · theforeman/foremanctl · GitHub. Ideally we would have made sure that was in packaging before RC1 was announced and we did have Release foremanctl 3.0.0 by arvind4501 · Pull Request #13986 · theforeman/foreman-packaging · GitHub.
@ogajduse perhaps no pipeline was kicked off after it was merged?
For Facter: So the open source facter gem doesn’t receive updates since two years. And it’s missing the `implementation` fact which we added to openfact. We also added a bunch of other fixes and enhancements to openfact. The ancient facterDB has no proper openfact factsets. So if foreman wants a maintained version of facter, that also matches what the openvox-agents use, we should update FacterDB and we must replace facter with openfact (which is a single line change in foreman itself and a couple of lines in the packaging repo).
@ogajduse perhaps no pipeline was kicked off after it was merged?
I added foremanctl-3.0.0 to RC1. It’s live at Index of /releases/5.0/el10/x86_64.
I’d add another missing thing - docs on how to switch from Puppet Server to OpenVox on existing Foreman installs. Is there something to do with the installer? Is just changing repos/switching packages ok? (If these docs exist, my bad for not finding them, just drop me a link)
It’s a drop-in replacement. You add the OpenVox repositories and do dnf upgrade. Running the installer after is recommended, but I don’t think it should be needed.
https://docs.openvoxproject.org/ could document this.
Some updates - I have updated to the RC1 images using foremanctl.
- foremanctl does not create the traditional bootstrap consumer RPM. I re-worked my registration process to not need it anymore, but I did find that a bit surprising.
- It seems that the libvirt provider is looking for the ssh binary, and can’t find it:
- It also appears that the foreman_telemetry package is not included:
bash-5.2$ rpm -qi foreman-telemetry
package foreman-telemetry is not installed
The libvirt provider problem is much more important to me - the important metrics from foreman are the apache stats; but bundling libvirt and not the ssh client might be very perplexing for some.
I remain very excited at having all the dependency hell tucked out of sight in the containers.
Yes, that one is expected. It’s been long deprecated and is now finally being removed.
It appears that the foremanctl parameter to install telemetry is currently “unmapped” – there’s currently no equivalent of the foreman-installer parameter in foremanctl at the moment.
