Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1821342

Summary:	"RSTRNT_PORT=8082 /distribution/reservesys" does not work with 0.2.0
Product:	[Retired] Restraint	Reporter:	Miloš Prchlík <mprchlik>
Component:	general	Assignee:	Daniel Rodríguez <danrodri>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	0.2.0	CC:	asavkov, baseos-ci, bpeck, breilly, cbeer, mastyk
Target Milestone:	0.2.1
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-05-20 07:20:28 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:

Description Miloš Prchlík 2020-04-06 15:36:59 UTC

Description of problem:


This is the task's output:


chmod a+x ./runtest.sh ./recipe_status
./runtest.sh
Failed to start exim.service: Unit exim.service not found.
Failed to start sendmail.service: Unit sendmail.service not found.
Failed to start opensmtpd.service: Unit opensmtpd.service not found.
** /distribution/reservesys PASS Score:0
Uploading resultoutputfile.log .done
./runtest.sh: line 21: kill: (11227) - No such process



Version-Release number of selected component (if applicable):

I believe this is related to the weekend maintenance and update of Restraint used by Beaker to 0.2.0.


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 4 Bill Peck 2020-04-07 12:56:09 UTC

Using the latest restraint client and server should not require RSTRNT_PORT to be defined at all.  Have you made sure the latest version of restraint is installed on the machine where you are initiating the client from?

Comment 10 Daniel Rodríguez 2020-05-19 14:04:10 UTC

As mentioned in the description, this was caused by the Restraint 0.2.0 release, where a number of breaking changes with previous release, 0.1.45, were introduced. We have addressed practically all of them in the upcoming next release, 0.2.1, although there is still some differences in behavior.

The main one being that in Restraint 0.2.0, the client launches restraintd in the test system, so you don't need to launch restraintd yourself. Because of this, the "-p, --port" option was removed from restraintd, and trying to pass the option just triggered a command line error, due to incorrect option.

In 0.2.1 we've recovered the "-p, --port", but if you have a restraintd instance running, you cannot use the restraint client to run a job in this instance.

With the fixes that we are introducing in 0.2.1, the task subject of this issue should work without any changes.

The restraintd instance is going to be launched by reservesys, and it will listen in port 8082, as the "-p, --port" option is back. And the client call,

restraint --host $RECIPE_ID=$RESERVED_HOST:$RSTRNT_PORT --job the_job.xml

Will just launch another restraintd instance listening on a free port and run the job there. Also note that the "-t, --host" option no longer accepts ":port/ssh_port", but instead of fail the parsing, we are ignoring these arguments and warning about deprecation.

Although these fixes should improve backwards compatibility, the proper solution is to update restraint usage to fit the version used.

I'm marking this as pending release for 0.2.1.