Bug 1493160

Summary:	otopi fails on every error message from yum
Product:	[oVirt] otopi	Reporter:	Yedidyah Bar David <didi>
Component:	Plugins.packagers	Assignee:	Yedidyah Bar David <didi>
Status:	CLOSED NOTABUG	QA Contact:	Pavel Stehlik <pstehlik>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	master	CC:	bugs, oourfali, sbonazzo
Target Milestone:	---
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:	2017-09-24 05:57:37 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Integration	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Yedidyah Bar David 2017-09-19 13:42:15 UTC

Description of problem:

$subject.

In particular, if a scriptlet fails, yum (usually?) considers this non-fatal, e.g. it might emit:

Yum Non-fatal POSTIN scriptlet failure in rpm package $package

and if such a failure happens when running yum from the command line, it will continue and finish its transaction. But if this happens inside otopi, otopi will rollback and abort.

Personally, I am not sure this is such a bad behavior. One might claim, that for the intended use-case - automation of various setup processes in oVirt - it's reasonable to require that scriptlets do not fail, and if they do, we should debug and fix them not to, rather than allow continuing (thus more likely ignoring the failure).

Main issue with this is IMO that it's confusing - that the output/log claims it was non-fatal and we still fail.

This behavior seems to have been introduced by the following patch:

https://gerrit.ovirt.org/10717

Seems like fixing this will not be very easy. I'll spend some more time looking.

IMO we can close this bug. I mainly opened it for visibility/documentation.

Comment 1 Yedidyah Bar David 2017-09-19 19:26:32 UTC

Managed to prepare a fix, so moving to POST.

I still think it's a risk.

The logic to decide if a scriptlet should fail the installation or not seems to be in [1][2].

Meaning, if the error (rc!=0) is in one of the scriptlets %pre, %preun, %pretrans, or in Verify, we should fail, otherwise just say it's a non-fatal error.

Should otopi adopt same behavior? Or keep existing, where every error from yum is fatal and causes otopi to rollback and abort?

[1] https://github.com/rpm-software-management/rpm/blob/master/lib/transaction.c#L1455
[2] https://github.com/rpm-software-management/yum/blob/master/yum/rpmtrans.py#L610

Comment 2 Sandro Bonazzola 2017-09-20 08:57:03 UTC

(In reply to Yedidyah Bar David from comment #1)
> Managed to prepare a fix, so moving to POST.
> 
> I still think it's a risk.
> 
> The logic to decide if a scriptlet should fail the installation or not seems
> to be in [1][2].

And looks like the dilemma is still open also in yum:
  # FIXME - what else should we do here? raise a failure and abort?

I would rather fail and rollback, I agree changing this is a risk and prefer to get scriptlet fixed instead of just ignore them.

Comment 3 Yedidyah Bar David 2017-09-24 05:57:37 UTC

Very well.

Summary:

If you run otopi (e.g. engine-setup, host-deploy, hosted-engine --deploy) and see something like that:

Yum Non-fatal POSTIN scriptlet failure in rpm package $package

Then:

1. you should likely see more errors later
2. otopi did fail, aborted, and rolled back changes it already did (or at least tried to), even though yum decided it's a "non-fatal" failure.