Bug 1361715

Summary: preupg exits with 255 with some result combinations
Product: Red Hat Enterprise Linux 6 Reporter: Alois Mahdal <amahdal>
Component: preupgrade-assistantAssignee: Michal Bocek <mbocek>
Status: CLOSED ERRATA QA Contact: Alois Mahdal <amahdal>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.8CC: fkluknav, jmazanek, jreznik, mbocek, ovasik, phracek, pstodulk, tcerna
Target Milestone: rcKeywords: Extras
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: preupgrade-assistant-2.2.0-1.el6 Doc Type: No Doc Update
Doc Text:
undefined
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-03-21 12:09:10 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:
Bug Depends On:    
Bug Blocks: 1335121, 1393496    

Description Alois Mahdal 2016-07-29 20:37:25 UTC
Description of problem
======================

In some cases, `preupg` ends with 255, even though everything else seems
to be OK.

I found this when running mysql module test, which runs all 4 database
modules in loop with varying presence of incompatible options or mysql
packages.

There seems to be corelation with results:

    notapplicable  notapplicable  notapplicable  notapplicable     FAIL
    notapplicable  pass           informational  informational     FAIL
    notapplicable  notapplicable  notapplicable  needs_action      PASS
    notapplicable  pass           informational  needs_action      PASS
    notapplicable  pass           informational  needs_inspection  PASS

It seems as if only cases containing at leasr "needs_inspection" or
"needs_action" behave normally.

The exact command run in the test is:

    preupg --force --select-rules 'xccdf_preupg_rule_databases_postgresql_pre,xccdf_preupg_rule_databases_mysql_data_migration_migration,xccdf_preupg_rule_databases_mysql_configuration_changes_configuration,xccdf_preupg_rule_databases_mysql_general_changes_general'


Version-Release number of selected component
============================================

preupgrade-assistant-2.1.8-2.el6
preupgrade-assistant-el6toel7-0.6.52-1.el6


How reproducible
================

Always (with this test)


Steps to Reproduce
==================

Schedule test /CoreOS/preupgrade-assistant/6to7/contents/mysql-configuration_changes:

    ipu sched -B -t /CoreOS/preupgrade-assistant/6to7/contents/mysql-configuration_changes | bash


Actual results
==============

Some subtests report failure due to exit status 255


Expected results
================

Exit status should be 0, 1 or 2 in all sub-tests (i.e. the preupg wrapper
should always report PASS)

Comment 1 Alois Mahdal 2016-07-29 21:44:14 UTC
This affects mosts tests, giving false positives.

Comment 4 Petr Hracek 2016-08-15 12:19:51 UTC
OK, I will look on it.
It is a pretty hard to test it, though.

Comment 5 Alois Mahdal 2016-08-15 14:30:04 UTC
(In reply to Petr Hracek from comment #4)
> OK, I will look on it.
> It is a pretty hard to test it, though.

It's probably hard to test the failure cases, but the "normal" cases (various result combinations, 0-3) should be relatively straightforward, and those are currently hurting us most.

(I'm planning to write test focused on the "normal" cases; and more in future cycles...)

Comment 9 Petr Hracek 2016-08-22 11:12:47 UTC
*** Bug 1368825 has been marked as a duplicate of this bug. ***

Comment 15 Michal Bocek 2016-12-14 12:51:47 UTC
In preupgrade-assistant-2.2.0-1.el6, preupg exits with code 1 or 2 on module failure/error. See the below table that show what exit codes are returned based on module results.

MODULE FUNC CALLS   || PREUPG BEHAVIOR
------.-------------||--------.-------------.
exit_x | log_x_risk || result | exit status |
=======|============||========|=============|
fail   | (none)     ||   fail |  2          |
fail   | slight     ||  n_ins |  0          |
fail   | medium     ||  n_ins |  0          |
fail   | high       ||  n_act |  1          |
fail   | extreme    ||   fail |  2          |
-------|------------||--------|-------------|
fixed  | *          ||  fixed |  0          |
-------|------------||--------|-------------|
info   | *          ||   info |  0          |
-------|------------||--------|-------------|
n_app  | *          ||   napp |  0          |
-------|------------||--------|-------------|
pass   | *          ||   pass |  0          |
-------|------------||--------|-------------|
error  | *          ||  error |  2          |
-------|------------||--------|-------------|
    exit_x or       ||        |             |
    log_x_risk      ||  error |  2          |
    not called      ||        |             |
-------|------------||--------|-------------|

Comment 17 Alois Mahdal 2017-01-31 14:33:34 UTC
/CoreOS/preupgrade-assistant/api/mseverity covers this, and it passes, so OK from me.

Comment 19 errata-xmlrpc 2017-03-21 12:09:10 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2017-0819.html