Description of problem: When a request requires an approval, trying to approve that request in the Global region causes an error "Response received from https://IP.REDACTED.FOR.CUSTOMER/ is not of type application/json [miq_request/stamp]" This occurs when a user logs in to the global, makes service provision request (that would go to a sub-region) that needs approval, and then tries to approve said request from the Global Region. Version-Release number of selected component (if applicable): 5.8.2.3.20171016155816_aaec796 How reproducible: Attempt to approve a request from the global region. Steps to Reproduce: 1. Have a Global region, with at least one sub-region replicating. The provider (vCenter in this case) lives in the sub-region. 2. Log in to the Global region, and do a service request to provision a VM in the provider that lives in the sub-region. 3. If the request requires approval, log in to the global reqion, and then try to approve the request. Notice the error that pops up afterwards. Actual results: Error will occur with the following message: "Response received from https://IP.REDACTED.FOR.CUSTOMER/ is not of type application/json [miq_request/stamp]" Expected results: Should have the ability to approve a request from the Global Region Additional info: Please see the attached screenshot for a better representation of the error. Customer will be opening a support case for this BZ, as this is hindering them from using the Global Region
Lynn, We need to get some more information and some clarification before we can proceed. First question is was the provision request initiated through the service UI or the OPS UI? I ask because none of the central admin features are currently supported in the service UI. Was the attempt to approve the request done with the OPS UI? Also, we'll need to get logs from the global appliance where the error is encountered while trying to approve the request so that we can see what the actual error is. The attached screen shot doesn't give us much information. Can you please try this again and grab the current logs from the appliance and send them to us? Thanks.
Discussing comment #5 with Alberto, he informed me that it is from a different request, but the same kind of error. We really need to see logs that correspond to the attempt to approve the request so that we can understand what is failing underneath. Can you please try to approve the request again and immediately collect the logs? We'd need to see the logs from both the global and remote appliances to get the full picture. From what we know so far the issue is likely to be on the remote side. In addition to the logs, it would be really helpful if you can let us know the timestamp in which the approval was made so that we can pinpoint it in the logs. Tanks!
https://github.com/ManageIQ/manageiq/pull/16708
New commit detected on ManageIQ/manageiq/master: https://github.com/ManageIQ/manageiq/commit/1eca9a8d65fd6ea16f7e1094a5bbef680feb6eb1 commit 1eca9a8d65fd6ea16f7e1094a5bbef680feb6eb1 Author: Brandon Dunne <bdunne> AuthorDate: Wed Dec 20 17:40:51 2017 -0500 Commit: Brandon Dunne <bdunne> CommitDate: Thu Dec 21 10:21:52 2017 -0500 Send IDs through exec_api_call as a regular param not a block When sending them through an array in a block, the client calls the action on the collection with an array of IDs. Unfortunately this returns an Array of ManageIQ::API::Client::ActionResults and Arrays aren't currently an expected response for this caller, so it will raise: "Got unexpected API result object Array" Rather than dealing with the confusion of calling .first on the array, allow an ID to be passed in. https://bugzilla.redhat.com/show_bug.cgi?id=1526009 Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1528339 app/models/mixins/inter_region_api_method_relay.rb | 13 ++--- .../mixins/inter_region_api_method_relay_spec.rb | 66 +++++++--------------- 2 files changed, 23 insertions(+), 56 deletions(-)
The original issue was the "Response received from https://x.x.x.x is not of type application/json" which I was only able to reproduce if the remote region was not responding to API requests. Is the "Got unexpected API result object Array" now the only error that you see? If so, I have a fix for that.
Hi Lynn, Are you able to reproduce the problem that was originally reported ("Response received from https://IP.REDACTED.FOR.CUSTOMER/ is not of type application/json [miq_request/stamp]")? The change I made will fix "Got unexpected API result object Array".
Hi Brandon, Has this made it into the CFME downstream in a dot release?
The fix for the other bug is in 5.8.3.1 and 5.9.0.15 (both currently on QA). Are you able to reproduce the original problem reported in this bug?
We haven't been able to fully reproduce unfortunately.
Should we close this bug since we can't reproduce the problem?
I don't see any issues with closing this, especially with the code you contributed upstream that is currently in CFME QA. If we are able to reproduce, we can simply re-open the BZ if necessary.
Sounds great, thanks.