Bug 1134954

Summary:	Call on apipie resource is too verbose in case of erroneous response
Product:	Red Hat Satellite	Reporter:	Matej Kollar <mkollar>
Component:	Hammer	Assignee:	Martin Bacovsky <mbacovsk>
Status:	CLOSED ERRATA	QA Contact:	Corey Welton <cwelton>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	Unspecified	CC:	achan, bbuckingham, cperry, cwelton, dcleal, jmontleo, mbacovsk, mkollar, mmccune, omaciel, sthirugn, xdmoon
Target Milestone:	Unspecified	Keywords:	Triaged
Target Release:	Unused
Hardware:	Unspecified
OS:	Unspecified
URL:	https://github.com/Apipie/apipie-bindings/pull/15
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:	Previously, API call unhandled exceptions were being passed to the client. These exceptions can be cryptic in nature. Now, when an unhandled exception happens on an API call, the error is translated to a debug message and passed to the client.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-11-13 22:28:55 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:	1134809

Description Matej Kollar 2014-08-28 13:46:52 UTC

Description of problem:

When called

  @api.resource(resource).call ...

returns erroneous response (say in case of creating entity that already exists)
it also prints error message in addition to re-raising exception.


Version-Release number of selected component (if applicable):
rubygem-apipie-bindings-0.0.8-1.el6sat.noarch

How reproducible: always/deterministic

Steps to Reproduce:
1. try to creat the same org twice
2. catch exception for the second and ignore it

Actual results:
  colourful message is printed 

Expected results:
  no message is printed

Additional info:
  maybe change log level to debug...

Comment 2 Martin Bacovsky 2014-08-28 14:40:17 UTC

PR: https://github.com/Apipie/apipie-bindings/pull/15

Comment 3 Martin Bacovsky 2014-08-28 15:09:42 UTC

The PR was merged in apipie-bindings upstream

Comment 4 Jason Montleon 2014-08-28 18:11:31 UTC

Has a new gem been released for this? apipie-bindings is built from gem downstream and it looks like 0.0.8 is still latest.

Comment 5 Martin Bacovsky 2014-08-29 11:13:46 UTC

Gem 0.0.9 was released.
Updated upstream spec is here https://github.com/theforeman/foreman-packaging/tree/rpm/develop/rubygem-apipie-bindings

Comment 10 Brad Buckingham 2014-09-22 13:30:16 UTC

Matej, can you provide an example of the erroneous output and the impact of this to the user?

Comment 11 sthirugn@redhat.com 2014-10-24 19:26:24 UTC

Nothing to test from QE stand point.  Reassigning back to lpramuk

Comment 12 Martin Bacovsky 2014-10-27 10:42:14 UTC

The problem was that the apipie-bindings logged error caught from server and re-risen it. While it was logged on ERROR loglevel, it was difficult to hide this message even when the server error was recovered.

I'm not sure about import tool, but from hammer it could be tested while creating entity that already exists e.g. architecture:

$> hammer -d architecture create --name x86_64

In the log there should be the message form API present with DEBUG log level (instead of ERROR)
[DEBUG 2014-10-27 11:36:48 API] 422 Unprocessable Entity

Comment 17 Corey Welton 2014-11-06 15:01:34 UTC

Verified in latest compose Satellite-6.0.4-RHEL-7-20141029.5

[DEBUG 2014-11-06 09:58:15 API] 422 Unprocessable Entity

Comment 19 errata-xmlrpc 2014-11-13 22:28:55 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://access.redhat.com/errata/RHBA-2014:1857

Comment 20 Red Hat Bugzilla 2023-09-14 02:46:32 UTC

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days