Bug 1466417 - Can't Provision Vm via V3 (using ovirt gem)
Summary: Can't Provision Vm via V3 (using ovirt gem)
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Providers
Version: unspecified
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: GA
: 5.9.0
Assignee: Juan Hernández
QA Contact: Angelina Vasileva
URL:
Whiteboard: rhev
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-06-29 14:26 UTC by Boriso
Modified: 2019-05-31 13:09 UTC (History)
6 users (show)

Fixed In Version: 5.9.0.1
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-03-01 13:14:47 UTC
Category: Bug
Cloudforms Team: RHEVM
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2018:0380 0 normal SHIPPED_LIVE Moderate: Red Hat CloudForms security, bug fix, and enhancement update 2018-03-01 18:37:12 UTC

Description Boriso 2017-06-29 14:26:03 UTC
Description of problem:

When trying to provision a Vm an error occurs.
MIQ(ManageIQ::Providers::Redhat::InfraManager::Provision#provision_error) [[Ovirt::UsageError]: ] encountered during phase [start_clone_task]

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


How reproducible:
100%

Steps to Reproduce:
1. Provision a Vm on rhv 4.0.7

Actual results:
Provision fails

Expected results:
Vm successfully provisioned.

Additional info:

The reason for the error (as found by Juan Hernandez) is that the oVirt gem sends the wrond header: "xml" instead of "application/xml" and the rhv Application server stopped accepting this header.

Comment 2 Juan Hernández 2017-07-03 08:52:35 UTC
A workaround to make this work is to configure the RHV web server so that it fixes the incorrect headers sent by CFME. To do so go to the RHV engine machine and do the following:

  # cat >> /etc/httpd/conf.d/fix-api-content-type.conf <<.
  <Location /ovirt-engine/api>
    RequestHeader edit Content-Type ^xml$ application/xml
    RequestHeader edit Accept ^xml$ application/xml
  </Location>
  .
  # systemctl restart httpd

Comment 3 Juan Hernández 2017-07-03 12:05:20 UTC
The change in behaviour is caused by the replacement in CFME of the 'mime-types' gem with 'mini_mime':

  Stub mini-mime in for mime-types
  https://github.com/ManageIQ/manageiq/pull/14525

The difference is that 'mime_types' doesn't convert 'xml' to 'application/xml', which is expected by 'rest-client' and also by the 'ovirt' gem:

  # Produces nil:
  require 'mini_mime'
  MiniMime.lookup_by_filename('xml')

  # Produces application/xml:
  MIME::Types.type_for('xml')[0]

This has been merged only to the CFME master branch, and not backported, so it won't affect released versions of CFME. I am lowering the severity as it does not affect released versions. We will still need to modify the 'ovirt' gem to explicitly use 'application/xml', but only for the master branch of CFME.

Comment 4 Juan Hernández 2017-07-03 12:12:46 UTC
I am also removing the cfme-5.7.z and cfme-5.8.z flag, as this only affects the CFME master, not any released version (assuming that the change to use 'mini_mime' won't be backported).

Jason, can you confirm that the change to 'mini_mime' won't be backported?

Comment 5 Juan Hernández 2017-07-03 12:30:22 UTC
The proposed solution to this issue is the following pull request:

  Use 'application/xml' explicitly
  https://github.com/ManageIQ/ovirt/pull/83

Comment 6 Juan Hernández 2017-07-03 18:56:13 UTC
The following pull request updates the oVirt provider to use version 0.17.1 of the 'ovirt' gem that contains the fix:

  Use 'ovirt' >= 0.17.1
  https://github.com/ManageIQ/manageiq-providers-ovirt/pull/56

Comment 7 Ilanit Stein 2017-11-09 18:32:01 UTC
Juan,

As in CFME-5.9, the default api is SDK (V4),
Is there a point in verifying this bug on CFME-5.9?
If yes, how can the switch to V3 can be done please?

Thanks.

Comment 8 Juan Hernández 2017-11-10 06:42:53 UTC
Yes, I think it is important to test this with CFME-5.9, because CFME-5.9 still has to work correctly with RHV-3.6.

The easiest and best way to test this is to test it with RHV-3.6. Alternatively, you can test it with RHV-4 changing this configuration setting to `false`:

  :ems:
  :ems_redhat:
    :use_ovirt_engine_sdk: true

Comment 9 Ilanit Stein 2017-11-19 09:14:58 UTC
Verified on CFME-5.9.0.9, with using ovirt_gem (api version V3), 
instead of the default use_ovirt_engine_sdk (api version V4)

# vi /opt/rh/cfme-gemset/bundler/gems/manageiq-providers-ovirt-07a914ee1691/config/settings.yml   

:ems: 
 :ems_redhat: 
   :product_version_to_api_version_regexps: 
     :'^3\..*$': 3 
     :'^4\..*$': 3 4 
   :use_ovirt_engine_sdk: true  <== changed this to false.

# systemctl restart evmserverd

VM provision from a template (with nic) was successful.

Comment 10 Ilanit Stein 2017-11-19 09:15:38 UTC
In continue to comment 9:
RHV version tested was 4.1.6

Comment 13 errata-xmlrpc 2018-03-01 13:14:47 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/RHSA-2018:0380


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