Bug 1255334 - [REST] response of DELETE watchdog is not in xml format
[REST] response of DELETE watchdog is not in xml format
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
Unspecified Unspecified
unspecified Severity medium
: ovirt-3.6.0-rc
: 3.6.0
Assigned To: Juan Hernández
Shira Maximov
: Automation
Depends On:
  Show dependency treegraph
Reported: 2015-08-20 06:12 EDT by Shira Maximov
Modified: 2016-04-19 21:30 EDT (History)
9 users (show)

See Also:
Fixed In Version: 3.6.0-10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-04-19 21:30:09 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: Infra
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 45065 None None None Never

  None (edit)
Description Shira Maximov 2015-08-20 06:12:10 EDT
Description of problem:
when deleting watchdog entity via rest API you don't receive an xml respond, because 'application/xml is missing in the response headers   

* Example of the DELETE via res: 


* Response headers :

Date: Thu, 20 Aug 2015 08:21:43 GMT 
Pragma: No-cache 
Cache-Control: no-cache 
Expires: Thu, 01 Jan 1970 02:00:00 IST 
Content-Type: */*  

Version-Release number of selected component (if applicable):
Red Hat Enterprise Virtualization Manager Version: 3.6.0-0.11.master.el6

How reproducible:

Steps to Reproduce:
1.create vm with watchdog device 
2.try to delete watchdog device via rest API

Actual results:

actions: null
brick: null
bricks: null
cluster: null
comment: null
connectivityTimeout: null
creationStatus: null
description: null
disk: null
disks: null
fault: null
fenceType: null
gracePeriod: null
host: null
hostNics: null
href: null
id: null
image: null
iscsi: null
job: {actions: null, comment: null, creationStatus: null, description: null, endTime: null,
  href: /ovirt-engine/api/jobs/e5213fc1-54aa-4baf-84ea-b6b7e61f02cc, id: e5213fc1-54aa-4baf-84ea-b6b7e61f02cc,
  lastUpdated: null, name: null, owner: null, startTime: null, status: null}
logicalUnits: null
modifiedBonds: null
modifiedLabels: null
modifiedNetworkAttachments: null
name: null
network: null
option: null
powerManagement: null
proxyTicket: null
reason: null
removedBonds: null
removedLabels: null
removedNetworkAttachments: null
resolutionType: null
rootPassword: null
snapshot: null
ssh: null
status: {detail: null, state: complete}
storageDomain: null
storageDomains: null
synchronizedNetworkAttachments: null
template: null
ticket: null
vm: null

Expected results:
the response should be xml

Additional info:
Comment 1 Juan Hernández 2015-08-20 06:46:52 EDT
This happens because the request doesn't include an "Accept" header, thus the application server is free to select whatever it likes. In this particular case it decides to send YAML. Not sure why, seems like the server selects randomly the response content type, and that the presence of headers like "Content-Type" have some influence.

Ideally we should solve this making "application/xml" the default for all responses, but I couldn't find yet a way to configure the default response type in Resteasy.

As a workaround include the "Accept: application/xml" header explicitly, that will force the server to use the expected media type.
Comment 2 Juan Hernández 2015-08-20 11:17:42 EDT
The fix for bug 1250046 also solves this issue.
Comment 3 Shira Maximov 2015-08-24 03:11:55 EDT
verified on 3.6.0-10

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