Foreman 2.1.0-rc3 release process

Make this post a wiki

Manual updates

  • Update manual if applicable for any additional installation steps
  • Update release notes section in the manual:
    • Release notes: bullet point list by category of all changes, include link to bug numbers. You can auto-generate changes using the release notes script.
    • CLI release notes are taken from the hammer-cli and hammer-cli-foreman changelogs
    • Link to installer changelogs and note versions being used
    • Headline features: half a dozen important features with a few sentences description each
    • Upgrade notes: all important notices that users must be aware of before upgrading

Preparing code

  • Make patch releases of installer modules that have important changes
    • Branch to MAJ.MIN-stable if recent changes to the module aren’t suitable for patch (x.y.z) release
  • Compare tagged packages in nightly vs. release koji tag and re-tag any updated dependencies that are required
  • Remove/change release field for any open Redmine tickets assigned to the release still (next minor, unset it or reject)
  • Ensure that code in git matches issues fixed in 2.1.0-rc3 in redmine. issues.rb can be used to generate a comparison between the two.

Tagging a release

  • In foreman 2.1-stable:
    • Make sure test_2_1_stable is green
    • run make -C locale tx-update (if Transifex has not switched to the next major release yet, usually after .2)
    • run script/
    • update template snapshots with rake snapshots:generate RAILS_ENV=test and verify changes are expected
    • Tag the release using 2.1.0-rc3
    • Push: git push upstream 2.1-stable --follow-tags
  • In smart-proxy 2.1-stable:
    • Make sure test_proxy_2_1_stable is green
    • Tag the release using 2.1.0-rc3
    • Push: git push upstream 2.1-stable --follow-tags
  • In foreman-selinux 2.1-stable:
    • Tag the release using 2.1.0-rc3
    • Push: git push upstream 2.1-stable --follow-tags
  • In foreman-installer 2.1-stable:
    • Tag the release using 2.1.0-rc3
    • Push: git push upstream 2.1-stable --follow-tags
  • Run the Jenkins Tarballs Release to create tarballs
  • Update release version similar to here
  • Sign Tarballs

Note: If for some reason there was an issue with the tarballs that required uploading new tarballs, CDN cache should be invalidated so that the builders use the updated tarballs.

Packaging a release

Background documentation

Tomer, I hope this an appropriate place to make this comment.

It would be nice to see Foreman 2.1rc3 on CentOS 8 address the current incompatibility between Foreman 2.1rc{1,2} and EPEL on CentOS 8.{1,2}.

Problem: If you have installed Foreman on CentOS 8, you can not install EPEL without creating a versioning problem on dnf upgrade. This problem existed in Foreman 2.1rc1, but as the basic install does not require EPEL, I simply didn’t install epel-release on CentOS 8. The problem raises it head again if you try to install Ansible related functionality, as ansible is provided from the EPEL repository. I’ll summarize the problem here, as the referenced thread is very long.

The commands to reproduce the problem on a CentOS 8 system with Foreman 2.1rc{1,2} installed:

sudo yum -y upgrade               # Nothing to do
sudo yum -y install epel-release
sudo yum -y upgrade               # Problem see below
sudo yum -y erase   epel-release
sudo yum -y upgrade               # Nothing to do

Just the error generated for brevity:

 Problem: package foreman-2.1.0-0.20.rc2.el8.noarch requires rubygem(net-ssh) = 4.2.0, but none of the providers can be installed
  - cannot install both rubygem-net-ssh-5.1.0-2.el8.noarch and rubygem-net-ssh-4.2.0-2.el8.noarch
  - cannot install both rubygem-net-ssh-4.2.0-2.el8.noarch and rubygem-net-ssh-5.1.0-2.el8.noarch
  - cannot install the best update candidate for package rubygem-net-ssh-4.2.0-2.el8.noarch
  - cannot install the best update candidate for package foreman-2.1.0-0.20.rc2.el8.noarch
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

PS: The reference to the longer running thread:

Thanks for bringing it up! We have actually just updated the manual for 2.1 (Foreman :: Manual) for EL8 instructions, and indeed EPEL is not required on EL8.

Re: manual update - I noticed that :slight_smile:

I just looked through the EPEL package list, and while I didn’t find anything that I immediately require on my Foreman server/proxies, I wouldn’t be surprised if a Perl/Python/Ruby module or other tool (collectd, hwinfo, htop, dpkg, proftpd, …) from EPEL does not make someone’s list of required packages.

If the problem can’t be fixed, I would put a “N.B. section” in the CentOS 8 specific part of the manual, that this is a known issue, or you can guarantee someone will raise an issue about it :wink:

1 Like

If I may be so bold, as a new to Foreman user, could I suggest that the QuickStart Guide, early on and possibly after the installation section, make the very specific recommendation that reading the “Provisioning Guide” will help make the understanding of Foreman for provisioning (which I assume is a common starting point for new users like myself), much much easier :wink:

I would also note that in the Foreman WebUI a number of plugins (and maybe other feature) documentation links are not valid; as the plugin website does not have a manual for the current version of the plugin - example: remote-execution is currently at version 3.3+ while the plugin website has documentation for 1.7 as the latest version.


Thanks for the feedback, I was literally discussing with @mcorr half an hour ago that we need to update some plugin manuals and see when and how we link to the new documentation guides from the main websites :slight_smile:

1 Like

I’ll raise a PR to point from the QSG to the provisioning guide as a start to this.

We quite literally depend on you being so bold, and we’re quite bold too, so thank you very much :slight_smile:

FWIW, Ansible is in CentOS8 “configuration management” repo, and we recommend to pull it from there (that is not in the release notes, I think), instead of EPEL

But I see your point with being able to use epel for other reasons, lemme see :slight_smile:

@illumino I’ve opened Bug #30162: Allow newer Net::SSH - Foreman to track this issue.

For the time being, you can add rubygem-net-ssh to the exclude list of the EPEL repo (something like exclude = rubygem-net-ssh in /etc/yum.repos.d/epel.repo), which should fix the issue for you.

1 Like