Bug 1600825 - restraint conflicts with rhts-test-env
Summary: restraint conflicts with rhts-test-env
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Restraint
Classification: Retired
Component: general
Version: 0.1.35
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: 0.1.36
Assignee: Matt Tyson 🤬
QA Contact: Dan Callaghan
URL:
Whiteboard:
: 1610118 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-07-13 06:49 UTC by Radek Bíba
Modified: 2018-09-17 05:53 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-09-17 05:53:03 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Beaker Project Gerrit 6207 0 None MERGED restraint rpm package conflicts with rhts-test-env 2020-05-14 21:10:29 UTC

Description Radek Bíba 2018-07-13 06:49:27 UTC
Description of problem:
Not sure if my workstation is in bad shape due to a combination of repos that aren't supposed to be enabled at the same time, but "yum update" fails here this way:

Transaction check error:
  file /usr/bin/rhts-report-result from install of restraint-0.1.35-1.el7bkr.x86_64 conflicts with file from package rhts-test-env-4.74-1.el7bkr.noarch

Is it an error on my side or should restraint obsolete rhts-test-env?

Version-Release number of selected component (if applicable):
restraint-0.1.35-1.el7bkr.x86_64 is an update in the beaker-harness repo
restraint-0.1.33-1.el7bkr.x86_64 was installed from the beaker-harness repo
rhts-test-env-4.74-1.el7bkr.noarch was installed from the beaker-client repo

Comment 1 Dan Callaghan 2018-07-13 07:03:40 UTC
Hmm I think this is (another) unintended side effect of https://gerrit.beaker-project.org/c/restraint/+/6087 ... rhts-report-result moved from the restraint-rhts subpackage into the main restraint package.

It has always been impossible to install rhts-test-env (the "real" or original implementations of the rhts-* commands) alongside restraint-rhts (restraint's compatibility wrappers of the rhts-* commands). They conflict, and also restraint-rhts provides rhts-test-env = 0 to prevent this.

However with this recent change which landed in restraint 0.1.35, it is now impossible to install rhts-test-env alongside restraint itself (even if you don't have the restraint-rhts compatibility wrappers). So that is not ideal.

I am guessing you have rhts-test-env on your workstation as a dependency of rhts-devel for building Beaker tasks... can I ask why you have restraint on your workstation, out of curiosity?

Comment 2 Radek Bíba 2018-07-16 06:51:35 UTC
I see, thanks. Not sure why restraint is installed, though. I don't remember installing it, but here's (at least some of) its history:

# grep restraint /var/log/yum.log*
/var/log/yum.log-20170102:Aug 05 16:22:07 Updated: restraint-0.1.25-2.el7_2.x86_64
/var/log/yum.log-20170102:Aug 18 16:36:02 Updated: restraint-0.1.26-1.el7_2.x86_64
/var/log/yum.log-20170102:Oct 21 16:39:48 Updated: restraint-0.1.27-1.el7_2.x86_64
/var/log/yum.log-20170102:Nov 11 16:27:54 Updated: restraint-0.1.28-1.el7_2.x86_64
/var/log/yum.log-20170102:Nov 25 17:36:53 Updated: restraint-0.1.29-1.el7_2.x86_64
/var/log/yum.log-20170102:Dec 22 18:21:48 Updated: restraint-0.1.30-1.el7_2.x86_64
/var/log/yum.log-20180102:Aug 18 12:59:56 Updated: restraint-0.1.31-1.el7bkr.x86_64
/var/log/yum.log-20180102:Oct 31 14:35:40 Updated: restraint-0.1.32-1.el7bkr.x86_64
/var/log/yum.log-20180516:Jan 05 15:59:14 Updated: restraint-0.1.33-1.el7bkr.x86_64

"yum history restraint" goes even deeper:

Transaction ID : 19
Begin time     : Fri Jul 31 16:16:20 2015
...
    Updated     qa-tools-workstation-3.9-23.x86_64             @qa-tools
    Update                           3.9-30.x86_64             @qa-tools
...
    Dep-Install restraint-0.1.21-1.el7.x86_64                  @beaker-harness
    Dep-Install restraint-rhts-0.1.21-1.el7.x86_64             @beaker-harness

That's interesting. I wonder if something (the updated qa-tools-workstation package) pulled in restraint-* because of rhts-test-env. At the moment, rhts-devel and qa-tools-workstation require rhts-test-env on my system.

As for restraint-rhts:

Transaction ID : 75
Begin time     : Mon Feb 29 08:43:57 2016
...
    Erase restraint-rhts-0.1.23-2.el7_2.x86_64 @beaker-harness

I don't know why I removed restraint-rhts two and a half years ago, sorry, but perhaps a similar conflict appeared at that time and I just got rid of it this way and switched to the rhts-test-env package.

Nothing requires restraint at the moment -- as I can see by running "rpm -e --test restraint". It looks like an orphan that I should just delete, I think.

Comment 3 Dan Callaghan 2018-07-16 22:20:59 UTC
Yeah certainly the workaround here is to just remove restraint from your workstation. You *probably* don't need it unless you are wanting to test your tasks locally.

But it's not an ideal solution. So we might need to rethink the move of rhts-report-result ...

Comment 4 Dan Callaghan 2018-07-16 23:43:32 UTC
Looking back on bug 1571784 the reason for moving rhts-report-result was because we need to set the BEAKERLIB_COMMAND_REPORT_RESULT env var to a command which accepts the rhts-report-result argument style (rstrnt-report-result argument order is different). But we need that to work even when plain restraint is installed without restraint-rhts.

So the solution was to set BEAKERLIB_COMMAND_REPORT_RESULT=/usr/bin/rhts-report-result and then move rhts-report-result into the main package.

However to avoid this conflict we should probably go with one of the alternatives originally discussed in https://gerrit.beaker-project.org/c/restraint/+/6087 instead.

My suggestion would be: make rstrnt-report-result check for --rhts as its first arg, and in that case activate rhts-report-result style argument parsing. Then we move rhts-report-result back into the restraint-rhts subpackage and make it be a shell wrapper which does: exec rstrnt-report-result --rhts "$@". And we set: BEAKERLIB_COMMAND_REPORT_RESULT=/usr/bin/rstrnt-report-result --rhts

Comment 5 Matt Tyson 🤬 2018-07-16 23:54:52 UTC
We could also check to see if BEAKERLIB_COMMAND_REPORT_RESULT is set as an environment variable and use that to activate the RHTS style argument parsing.

This would probably be simpler to implement as the report-result executable decides which arg parsing codepath to use before it looks at command line switches.

Alternatively we could just loop over argv[] and do a strcmp() looking for "--rhts" without using glib to check for "--" style arguments.

Comment 6 Matt Tyson 🤬 2018-07-17 00:18:24 UTC
(In reply to Matt Tyson from comment #5)
> We could also check to see if BEAKERLIB_COMMAND_REPORT_RESULT is set as an
> environment variable and use that to activate the RHTS style argument
> parsing.
> 

If we take this approach we can do without the wrapper script and just use the binary directly, which IMO is a bonus.

Comment 7 Dan Callaghan 2018-07-17 00:19:35 UTC
But BEAKERLIB_COMMAND_REPORT_RESULT is always set, isn't it?

Comment 8 Matt Tyson 🤬 2018-07-17 00:26:19 UTC
(In reply to Dan Callaghan from comment #7)
> But BEAKERLIB_COMMAND_REPORT_RESULT is always set, isn't it?

Yes, you're right.  Scratch that idea.

Comment 9 Radek Bíba 2018-07-17 06:02:06 UTC
I'm pretty sure I can live without restraint on my workstation. I seldom run tests directly on my workstation, but when I do, I (only) need things like /usr/bin/rhts-environment.sh and /usr/share/rhts/lib/rhts-make.include, both of which are in rhts-test-env and not in restraint. If I remove restraint, I'll be able to update my system without having to skip/exclude restraint, which is what I need to do now. You're right however that it's just a workaround for me, and if there's a real solution in the way the packaging is done then please go ahead with it.

Comment 10 Matt Tyson 🤬 2018-07-17 06:46:28 UTC
I've gone with Dan's recommendation described in comment 4.

Comment 12 Roman Joost 2018-07-25 03:11:02 UTC
This can now be tested on https://beaker-devel.app.eng.bos.redhat.com/ with Restraint 0.1.35-1.git.9.bb4a7eb

Comment 13 Dan Callaghan 2018-08-07 06:49:41 UTC
Verified that restraint and rhts-test-env can be installed together without conflicts:

$ rpm -q rhts-test-env restraint
rhts-test-env-4.73-1.git.3.80405d6.el6bkr.noarch
restraint-0.1.35-1.git.15.a6282f5.el6bkr.x86_64

However, it doesn't actually work (bug 1610118).

$ cat job.xml 
<job>
  <whiteboard>verifying bz1600825</whiteboard>
  <recipeSet>
    <recipe whiteboard="" role="RECIPE_MEMBERS" ks_meta="harness=restraint-rhts" kernel_options="" kernel_options_post="">
      <task name="/distribution/dummy" role="STANDALONE">
<fetch url="file:///home/dcallagh/work/beaker-core-tasks/utils/dummy.tar.bz2"/>
</task>
    </recipe>
  </recipeSet>
</job>
$ restraint -vvv -j job.xml -t 1=localhost
Using ./job.04 for job run
Connecting to http://localhost:8092/run for host: localhost:8081, recipe id:1
[...]
[localhost           ] ** Running task: 1 [/distribution/dummy]
[localhost           ] use_pty:FALSE /usr/share/restraint/plugins/run_task_plugins make run
[localhost           ] /usr/share/restraint/plugins/task_run.d/15_beakerlib: line 10: export: `--rhts': not a valid identifier

Comment 14 Dan Callaghan 2018-08-07 06:50:33 UTC
*** Bug 1610118 has been marked as a duplicate of this bug. ***

Comment 17 Dan Callaghan 2018-08-23 03:33:36 UTC
$ rpm -q rhts-test-env restraint restraint-client
rhts-test-env-4.73-1.git.3.80405d6.el6bkr.noarch
restraint-0.1.35-1.git.17.c90da2e.el6bkr.x86_64
restraint-client-0.1.35-1.git.17.c90da2e.el6bkr.x86_64
$ restraint -vvv -j job.xml -t 1=localhost
Using ./job.11 for job run
Connecting to http://localhost:8091/run for host: localhost:8081, recipe id:1
[localhost           ] ** Fetching task: 1 [/mnt/tests/home/dcallagh/work/beaker-core-tasks/utils/dummy.tar.bz2]
[localhost           ] ** Extracting ./
[localhost           ] ** Extracting ./PURPOSE
[localhost           ] ** Extracting ./Makefile
[localhost           ] ** Extracting ./testinfo.desc
[localhost           ] ** Extracting ./runtest.sh
[localhost           ] ** Preparing metadata
[localhost           ] ** Updating env vars
[localhost           ] ** Updating external watchdog: 1920 seconds
[localhost           ] ** Installing dependencies
[localhost           ] ** Running task: 1 [/distribution/dummy]
[localhost           ] use_pty:FALSE /usr/share/restraint/plugins/run_task_plugins make run
[localhost           ] chmod 755 ./runtest.sh
[localhost           ] ./runtest.sh
[localhost           ] ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
[localhost           ] ::   Test
[localhost           ] ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
[localhost           ] :: [ 13:33:00 ] :: [   PASS   ] :: Nothing to do 
[...]

Comment 18 Dan Callaghan 2018-09-17 05:53:03 UTC
Restraint 0.1.36 was released on 24 August.


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