Bug 1599136 - [RFE] provide a documented way to run recipes where Beaker does not have harness packages for the distro (skip harness repo check)
Summary: [RFE] provide a documented way to run recipes where Beaker does not have harn...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Beaker
Classification: Retired
Component: general
Version: 25
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: 26.0
Assignee: Dan Callaghan
QA Contact: tools-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-07-09 03:18 UTC by Dan Callaghan
Modified: 2018-10-08 02:16 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-10-08 02:16:45 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Beaker Project Gerrit 6195 0 None MERGED Use ks_meta variable to disable default harness repository 2020-02-03 20:38:56 UTC

Description Dan Callaghan 2018-07-09 03:18:32 UTC
Beaker 25.4 has the following convoluted little piece of logic in Server/bkr/server/model/scheduler.py as part of the recipe.provision() method:

2584         if 'contained_harness' not in install_options.ks_meta \
2585            and 'ostree_repo_url' not in install_options.ks_meta:
2586             if 'harness' not in install_options.ks_meta and not self.harness_repo():
2587                 # raise ValueError only if distro is not user-defined
2588                 if self.distro_tree:
2589                     raise ValueError('Failed to find repo for harness')

The original purpose of this check was to ensure that there is a suitable repo in /var/www/beaker/harness/ containing the harness packages matching the recipe's distro (bug 722367). Imagine you have a fresh Beaker installation, or you have imported a new major version of RHEL into your Beaker instance for the first time. When you run a recipe, Beaker fills in a repo with id "beaker-harness" which is supposed to contain the harness packages which will be installed in your recipe. If you have not yet run beaker-repo-update, that repo will not exist in /var/www/beaker/harness and the installation will fail in a confusing way. Hence the check.

But the check is not always desirable. There have been a number of situations where we want to relax the check and allow the recipe to run even though there is no proper repo in /var/www/beaker/harness. These are the various negative clause in the convoluted conditional.

1. if the recipe is running on an OSTree-based distro (like Fedora Atomic) where you cannot install packages ('ostree_repo_url' will be defined in ksmeta in this case), or if the recipe is running on a regular distro but you still use the 'contained_harness' support -- in this case, the harness will not match the distro you are actually provisioning, it will match the distro inside the container instead, and will not be installed via yum directly at all (bug 1157348)

2. if the recipe uses a custom harness that is not included in the standard Beaker harness repos, the harness packages are supposed to come from another repo configured in the recipe instead (bug 1005865)

3. if the recipe uses a custom distro that has never been imported into Beaker  (bug 911515), in this case the recipe must supply another repo where the harness can be installed from

Roman noticed this while working on bug 1589610. That bug means that the harness= ksmeta variable will now always be set to *something* by default, and thus the harness repo check will always be skipped.

In other words, the current code is assuming that the presence of the harness= ksmeta variable indicates a *custom* harness (or "alternative harness" as the feature was originally designed) is being requested, for scenario number 2 above. But that is no longer true.

Instead of continuing to expand this convoluted and undocumented logic, Beaker should have a well-defined and documented way of opting out of the harness repo check.

Comment 1 Dan Callaghan 2018-07-09 23:58:26 UTC
Two ideas come to mind:

* A ksmeta to control whether Beaker will supply a default harness repo in the recipe. Call it "no_default_harness_repo" since we will always configure the harness repo by default. If you define "no_default_harness_repo" then we leave out the default harness repo (and thus don't check that it exists either). It's up to the job submitter to supply some working harness packages somehow.

* If the recipe defines its own repo with id "beaker-harness", we already use that in place of the default repo. However I think we still (needlesssly) do the harness repo check. We could make this id be a special case which means, "do not supply the default harness repo because I am supplying my own" and then skip the harness repo check as well. This magic repo id would need to be documented somewhere (the behaviour is currently totally undocumented). I'm not sure where.

Comment 2 Roman Joost 2018-07-10 06:46:44 UTC
Hm... I first thought using the second idea is the way to go, but realised that it's actually not really a nice solution.

Accessing the 'beaker-harness' variable in the template is a no go anyway, because Jinja parses this as a Python expression (you're subtracting a string from an undefined). Ignoring this, and simply using what the user had provided wholesale feels like a good way to get weird behaviour.

So I took the first route, since that is more explicit. You're opting out that Beaker provides you with a default harness. Supply your own via ks_appends.

Comment 3 Dan Callaghan 2018-07-10 07:05:07 UTC
There is no such variable "beaker-harness". It is a repo id.

Comment 6 Dan Callaghan 2018-10-08 02:16:45 UTC
Beaker 26.0 has been released.


Note You need to log in before you can comment on or make changes to this bug.