Description of problem: After upgrading rhevm from 3.6 to 4.0 CloudForms is unable to collect inventory [----] D, [2017-02-28T16:03:07.673741 #13288:e27d04] DEBUG -- : MIQ(Rbac::Authorizer#role_allows?) Auth successful for user 'cfs', role 'EvmRole-super_administrator', feature identifier 'ems_infra_edit' [----] I, [2017-02-28T16:03:07.940981 #13288:e27d04] INFO -- : MIQ(ManageIQ::Providers::Redhat::InfraManager#with_provider_connection) Connecting through ManageIQ::Providers::Redhat::InfraManager: [GVA RHEV] [----] I, [2017-02-28T16:03:07.941190 #13288:e27d04] INFO -- : MIQ(ManageIQ::Providers::Redhat::InfraManager#connect) Using stored API path '/api'. [----] D, [2017-02-28T16:03:07.941575 #13288:e27d04] DEBUG -- : MIQ(VMDB::Config#initialize) VMDB::Config.new is deprecated. Prefer using Settings directly. [----] D, [2017-02-28T16:03:07.941628 #13288:e27d04] DEBUG -- : MIQ(VMDB::Config#config) VMDB::Config#config is deprecated. Prefer using Settings directly. [----] E, [2017-02-28T16:03:07.969314 #13288:e27d04] ERROR -- : <RHEVM> Ovirt::Service#parse_error_response Return from URL: <https://lxvgvarhvprd01p.corp.ubp.ch/api> Data:<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>404 Not Found</title> </head><body> <h1>Not Found</h1> <p>The requested URL /api was not found on this server.</p> </body></html> [----] W, [2017-02-28T16:03:07.969666 #13288:e27d04] WARN -- : MIQ(ManageIQ::Providers::Redhat::InfraManager#authentication_check_no_validation) type: ["default"] for [42000000000005] [GVA RHEV] Validation failed: unreachable, Invalid URI specified for the server. [----] E, [2017-02-28T16:03:07.969825 #13288:e27d04] ERROR -- : MIQ(ems_infra_controller-update): Credential validation was not successful: Invalid URI specified for the server. ^C Version-Release number of selected component (if applicable): 5.7.* How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
The support for checking the version of oVirt and automatically updating the endpoint path was added in 5.7.0.13: Add features based on supported_api_versions to RedHat provider https://github.com/ManageIQ/manageiq/pull/11418/files I suggest that we verify that verify that the upgrade of RHV works correctly with the latest version 5.7.z version of CFME, and then close this bug as CURRENTRELEASE. Meanwhile, users that have an older version of CFME can workaround the issue manually updating the 'path' column in the database: update endpoints set path='/ovirt-engine/api' where path='/api/ and id='...' Makes sense?
I did verify this with 5.7.0.17, and it worked correctly for me, that is why I assumed that the customer was using an older version. Note that the API path is stored in the database, and updated only when running a full refresh. Maybe that is what the customer didn't do. I will re-test.
I repeated my tests and I can see that CFME doesn't automatically upgrade the stored 'path' to work correctly with oVirt 4. So we have two options: 1. Document this behavior and tell users to run the following when upgrading oVirt from 3.6 to 4.0 *if* it is combined with CFME 5.7.z: update endpoints set path='/ovirt-engine/api' where path='/api' 2. Change the provider so that it does never use the 'path' stored in the 'endpoints' table. Initially we didn't want to do that because it means an additional HTTP request for each connection between CFME and oVirt. Which option do we want?
The proposed solution to this issue is to add a database migration that automatically changes the 'path' column of the 'endpoints' table from '/api' to '/ovirt-engine/api': Migrate oVirt API path from /api to /ovirt-engine/api https://github.com/ManageIQ/manageiq/pull/14336
As the data migration doesn't help users of version 5.7, we will change the provider so that it always uses /ovirt-engine/api: Drop support for oVirt /api, always use /ovirt-engine/api https://github.com/ManageIQ/manageiq/pull/14469
The use of the `/api` path to collectsevents for version 3.x of RHV is expected, and won't cause problems. What is important to verify in this bug is that the `/api` path isn't used after upgrading to RHV 4.x, not for inventory collection neither for event collection, as it would not work. A side effect of the fixes is that even for RHV 3.x the provider will use the `/ovirt-engine/api` path for inventory collection, but that isn't an issue and doesn't need to be verified.
Verification steps: 1. I had machine A with RHEL6 and RHV 3.6.12.3 2. I got machine B with RHEL7 3. I got CFME appliance version 5.9.0.17 4. Added RHV 3.6 from machine A to the appliance 5. Backed-up config of RHV 3.6 (engine-backup) 6. Installed RHV 4.0.7.5 on machine B 7. Restored config from machine A RHV 3.6 to machine B RHV 4.0 8. Renamed RHV 4.0 on machine B (ovirt-engine-rename) 9. Edited the original provider in CFME appliance to have the new hostname 10. Started refresh for the Provider 11. Inspected rhevm.log on the appliance Expected result: <engine_url>/api should not be used after upgrading to 4.0. Only <engine_url>/ovirt-engine/api should be used. Actual result: /api path is still used. For example: Ovirt::Service#resource_get: Sending URL: <engine_url/api/events?from=1137> For details see the attached "rhevm.log from verification" and search for ".com/api". All content in rhevm.log was logged after upgrade from RHV 3.6 to RHV 4.0.
Updated the doc text and doc type fields.
Andrew, we don't have anything work there, this bug should be closed once we have updated the documentation. So can we close it?
Hi Martin, Thank you for your needinfo request. The known issue doc text has been added to the release notes, so if that is alright, there is nothing on the documentation side that should prevent this bug from being closed. Kind regards, Andrew
Thanks Andrew, so based on above moving to VERIFIED
(In reply to Andrew Dahms from comment #52) > Hi Martin, > > Thank you for your needinfo request. > > The known issue doc text has been added to the release notes, so if that is > alright, there is nothing on the documentation side that should prevent this > bug from being closed. > > Kind regards, > > Andrew Andrew, just small targeting question: is it contained in 5.9.0 release notes or 5.9.1 only? Just asking if we should not retarget to 5.9.0 ...
Hi Martin, Thank you for your needinfo request. To confirm - this release note is included in the 5.9.0 version of the Release Notes document. If it makes more sense to align the target milestone with that, then I agree that 5.9.0 sounds more appropriate. Kind regards, Andrew
Unfortunately I'm no longer able to move the bug to 5.9.0, but the important thing is that the message is included in 5.9.0 release notes. Thanks Andrew.