Bug 1599136
| Summary: | [RFE] provide a documented way to run recipes where Beaker does not have harness packages for the distro (skip harness repo check) | ||
|---|---|---|---|
| Product: | [Retired] Beaker | Reporter: | Dan Callaghan <dcallagh> |
| Component: | general | Assignee: | Dan Callaghan <dcallagh> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | tools-bugs <tools-bugs> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 25 | CC: | dcallagh |
| Target Milestone: | 26.0 | Keywords: | FutureFeature, Patch |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-10-08 02:16:45 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. 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. There is no such variable "beaker-harness". It is a repo id. Beaker 26.0 has been released. |
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.