In the past our approach to provisioning end-of-life'd (EOL'ed) Fedora releases was that it was unsupported, don't do it. Mainly that's because we don't maintain the harness for older Fedora releases -- there is no easy way to build it once the buildroots are deleted at EOL-time, and also it would mean eventually having to support a large variety of different versions of the platform (including ones with unresolved bugs). However, the ability to provision old Fedora releases in Beaker is useful, for comparing against new releases and testing which release might have introduced some bug. We can easily support EOL'ed Fedora on a "best effort" basis -- that is, using the harness packages that existed when the release was still active. This comes basically for free, since we leave the old Fedora harness repos in place (actually up to F18 we were deleting them, I have resurrected back to F16 which is the oldest we have tracked in git). It does mean that any harness bugs which existed in those old versions will remain unfixed forever. The only blocker to actually provisioning EOL'ed releases in Beaker right now, is that the fedora-release package configures the "fedora" and "fedora-updates" yum repos on the installed system, but the repos are deleted which causes yum to refuse to install anything: [...] + yum -y install beah rhts-test-env beakerlib Loaded plugins: langpacks, presto, refresh-packagekit Error: Cannot retrieve metalink for repository: fedora. Please verify its path and try again + yum -y install beakerlib-redhat Loaded plugins: langpacks, presto, refresh-packagekit Error: Cannot retrieve metalink for repository: fedora. Please verify its path and try again [...] If the Fedora tree still exists on the lab mirror (which it must, for Beaker to offer to provision it at all) then yum can just use that, the "fedora" repo is not needed. "fedora-updates" will have to be disabled since there is nowhere to get updates, but in most cases that won't affect provisioning. There is actually a broader issue which is that Beaker expects the distro not to come with any yum repos pre-configured (this is true for RHEL in its initial state). Instead, the distro repos will be provided by Beaker pointing at the lab mirror (along with any other custom repos defined in the job) and this will exactly match the set of repos used at install time. But Fedora breaks this assumption. The installation will use the tree on the lab mirror as provided by Beaker, plus fedora-updates (if no_updates_repos is not defined). But after installation, Beaker will have configured the tree on the lab mirror *and* fedora-release will have configured the "fedora" and "fedora-updates" repos. So there is already inconsistency when provisioning Fedora. (CentOS may be in the same situation, I haven't checked.) The best solution is probably in kickstart %post, before anything else, to disable the "fedora" repo configured by fedora-release (and also the "fedora-updates" repo, if no_updates_repos is defined). Then the post-install repo configuration will match the install-time repo configuration, and will use only the tree on the lab mirror (plus updates if not disabled). Then it should be possible to provision EOL'ed Fedora releases, assuming no_updates_repos is set.
(In reply to Dan Callaghan from comment #1) > The best solution is probably in kickstart %post, before anything else, to > disable the "fedora" repo configured by fedora-release (and also the > "fedora-updates" repo, if no_updates_repos is defined). Then the > post-install repo configuration will match the install-time repo > configuration, and will use only the tree on the lab mirror (plus updates if > not disabled). Then it should be possible to provision EOL'ed Fedora > releases, assuming no_updates_repos is set. On Gerrit: http://gerrit.beaker-project.org/#/c/4259/ Verified the patch on Fedora 17 with no_updates_repos is set.
On Fedora 19, even when beah is successfully installed the recipe will still fail because the beah services are not correctly enabled in kickstart %post: + systemctl enable beah-srv Operation failed: Invalid argument + systemctl enable beah-beaker-backend Operation failed: Invalid argument + systemctl enable beah-fwd-backend Operation failed: Invalid argument Running the same commands after installation works fine. I'm not sure why this would happen, seems like it must be a bug in the systemd RPM macros. Given that F19 is EOL and we can't build any new harness packages there is not much point spending any more effort to fix this.
Need to use sed as yum-config-manager is not assailable on all the distros when disabling yum repos. on Gerrit: http://gerrit.beaker-project.org/#/c/4333/
Beaker 21.0 has been released.