Introduction of a new katello-release RPM

ekohl · August 3, 2022, 3:28pm

Short summary:

A new RPM katello-release will be created in the Foreman repo
katello-release will obsolete katello-repos
katello-release will conflict with foreman-release

Background

Today we have a foreman-release RPM (like https://yum.theforeman.org/releases/latest/el8/x86_64/foreman-release.rpm) containing the GPG key and yum’s foreman.repo and foreman-plugins.repo. Then there’s a katello-repos RPM (like https://yum.theforeman.org/katello/4.5/katello/el8/x86_64/katello-repos-latest.rpm) which depends on foreman-release (without a version) and adds katello.repo.

Additionally, there’s also a foreman-client-release which is for the foreman-client repository.

The Foreman repositories follow Foreman’s version number (like /releases/3.3 and /plugins/3.3) while Katello repos use Katello’s version number (like /katello/4.5).

The user is required to find the right combination to install. A mismatch can’t work. This adds a burden on users.

Introducing a new katello-release RPM package

The new RPM package will contain all the needed .repo files. This means users can’t mismatch anymore.

To reduce maintenance efforts, it is proposed that it becomes a subpackage of foreman-release. There we already have all the needed files, removing the need to duplicate them. It is painful to publish a subpackage from to a different repository, so it is easier if we publish the package in the Foreman repository, just like we publish foreman-installer-katello there already.

It should obsolete katello-repos with a version constraint that depends on the branch. For example, katello-release-3.4.0 (which brings Katello 4.6) should obsolete katello-repos < 4.7.

On a technical level foreman-release and katello-release should conflict with each other. This does mean migration for existing katello users can be harder. An obsoletes on older foreman-release versions may result in existing foreman users getting the katello release file instead. The upgrade instructions can suggest dnf install --allowerasing which means DNF can do the swap for the user. The alternative is an explicit removal. This should be verified in practice.

Additionally, we have code to maintain the foreman-release.rpm symlink (which points to the latest version). This should be enhanced to also deal with katello-release. The code for that is here:

github.com

theforeman/foreman-infra/blob/3a03bf3249a8885d76f69bebe68017af966fabd9/puppet/modules/web/files/deploy-yumrepo.sh#L33-L46

    
      
          			latest=$(ls -t foreman-release-[0-9]*.rpm 2>/dev/null | head -n1)
          			if [[ -n "$latest" ]] ; then
          				ln -sf "$latest" foreman-release.rpm
          			fi
          
          
			latest=$(ls -t foreman-client-release-[0-9]*.rpm 2>/dev/null | head -n1)
          			if [[ -n "$latest" ]] ; then
          				ln -sf "$latest" foreman-client-release.rpm
          			fi
          
          
			latest=$(ls -t katello-repos-[0-9]*.rpm 2>/dev/null | head -n1)
          			if [[ -n "$latest" ]] ; then
          				ln -sf "$latest" katello-repos-latest.rpm
          			fi

github.com

theforeman/foreman-infra/blob/3a03bf3249a8885d76f69bebe68017af966fabd9/puppet/modules/web/files/deploy-yumrepo.sh#L87

    
      
          			rm -rf "${REPO_INSTANCE_PATH_PREV}"
          		fi
          	fi
          }
          
          
purgecdn() {
          	awk '/ CHANGED /{print $5}' "${REPO_RSYNC_LOG}" | xargs --no-run-if-empty fastly-purge "https://yum.theforeman.org/${REPO_DEST}"
          	set +f
          	for d in "${REPO_PATH}"/*; do
          		purge_base="https://yum.theforeman.org/${REPO_DEST}/$(basename $d)"
          		fastly-purge ${purge_base} foreman-release.rpm foreman-client-release.rpm katello-repos-latest.rpm
          	done
          	set -f
          }
          
          
REPO_SOURCE=$1
          REPO_DEST=$2
          OVERWRITE=${3:-false}
          MERGE=${4:-false}
          
          
if [[ -z $REPO_SOURCE ]] || [[ -z $REPO_DEST ]] ; then

Considerations

This does not change the structure on yum.theforeman.org. Changing that takes more time and introducing a new katello-release RPM is a quick win. Additionally, if the repositories do change in the future, this change makes it easier because the installation instructions won’t change.

Users syncing the repositories themselves (for offline access or otherwise) still need to match up versions. For them this is no solution. However, they can read the files in katello-release so see which repositories they need to sync.

Timeline

Due to priorities we will only start this work after Foreman 3.4 has been branched. This means it will be unlikely to land in RC1, but it can be included in RC2. If this works well, it can even be introduced in stable branches, but initially that’s considered out of scope.

upadhyeammit · August 9, 2022, 2:42pm

I have just forked a new Redmine issue to track this: Feature #35348: Introduction of a new katello-release RPM - Packaging - Foreman

evgeni · August 11, 2022, 8:18am

On the technical (install) side: there is also dnf swap which e.g. CentOS used to replace centos-linux-release with centos-stream-release.

And a question: Would the resulting RPM then live only in the Foreman repo, or cross-tagged to Katello too? The later allows for dnf install https://yum.theforeman.org/katello/VERSION/katello-release-latest.rpm so the user is only concerned about the Katello version they are installing, as otherwise they would still need to know the “matching” Foreman version (but have no possibility to mix the two up).

I think, from a project perspective, the Katello version shouldn’t play a such “big” role and users and docs should orient on the Foreman version, but at the same time I am not sure how easy that would fit into users minds?

ekohl · August 11, 2022, 8:28am

Good point.

I don’t think that’s needed. Instead we should starting using Foreman versions. That implies a Katello version, just like a Foreman version also implies REX x.y.z (because it’s in foreman-plugins-x.y) but users shouldn’t care too much about it.

Agreed and https://docs.theforeman.org/ already starts to take that approach. URLs only use the Foreman version.