Description of problem: It seems that in some cases the inventory refresh against OpenShift 3.1 is failing: [----] E, [2016-10-21T04:16:47.168155 #13801:4ab9498] ERROR — : MIQ(ManageIQ::Providers::OpenshiftEnterprise::ContainerManager::EventCatcher::Runner#start_event_monitor) EMS [ose.example.com] as [] Event Monitor Thread aborted because [undefined method `rindex' for nil:NilClass] [----] E, [2016-10-21T04:16:47.168530 #13801:4ab9498] ERROR — : [NoMethodError]: undefined method `rindex' for nil:NilClass Method:[rescue in block in start_event_monitor] [----] E, [2016-10-21T04:16:47.168799 #13801:4ab9498] ERROR — : /opt/rh/cfme-gemset/gems/kubeclient-2.1.0/lib/kubeclient/common.rb:129:in `parse_definition' Relevant code in kubeclient is: def self.parse_definition(kind, name) ... prefix = kind[0..kind.rindex(/[A-Z]/)] # NetworkP ... end Version-Release number of selected component (if applicable): CFME 5.7 OpenShift 3.1 Actual results: Refresh fails on parsing OpenShift objects definition. Expected results: Refresh should succeed. Additional info: This bug was encountered by Loic, who may have more information/logs, etc.
Without reproducing this bug, I've submitted a possible fix (https://github.com/abonas/kubeclient/pull/209) to handle a 'nil' kind. This behavior is strange and unexpected, since we would expect that each resource would have a well defined kind. However, in order to reproduce this bug I will need more information or help with the suitable openshift version.
- I don't quite believe the symbol-vs-string theory, as it comes straight from JSON.parse in `discover` method, should all be strings. - Here are /api/v1 and /oapi/v1 responses I'm getting from Origin 1.1 and 1.2: https://gist.github.com/cben/f8f051cb49fbbe207c833ab3eaf38e0c all have a string 'kind'. My current best wild guess is we're hitting some wrong/unexpected URL during discovery, I'll start tracing the actual URLs...
*** Bug 1391066 has been marked as a duplicate of this bug. ***
Loic, Federico, do we know that inventory refresh was failing? The 2 backtraces we have (bug 1391066 had a more detailed one) both suggest only event monitor failed. Loic, if you happen to still have full logs or an env where this reproduces, it could help us.
As commented in the duplicate bz, If this bug keeps reproducing it could be very helpful to get the result of: curl -k https://<openshift_master_url>:8443/api/v1
Bug fix in kubeclient: https://github.com/abonas/kubeclient/pull/209 Bumping kubeclient version: -kubeclient: https://github.com/abonas/kubeclient/pull/212 -manageiq-gems-pending: https://github.com/ManageIQ/manageiq-gems-pending/pull/11
Euwe PR: https://github.com/ManageIQ/manageiq/pull/12667
5.7 BZ should be POST also, but looks like the BZ hasn't been created yet.
Returning to ON_DEV as the patch didn't solve it. We finally got a working OSE3.1 to work with (thanks QE!), and unlike Origin it doesn't include "kind" fields in /[o]api/v1 responses *at all*: https://gist.github.com/cben/f8f051cb49fbbe207c833ab3eaf38e0c (scroll down to OSE3.1.1.8-api-v1.json, OSE3.1.1.8-oapi-v1.json)
Bug fix - Adding backward compatibility for 3.1 in kubeclient: https://github.com/abonas/kubeclient/pull/214
(In reply to Beni Paskin-Cherniavsky from comment #5) > Loic, Federico, do we know that inventory refresh was failing? > The 2 backtraces we have (bug 1391066 had a more detailed one) both suggest > only event monitor failed. > > Loic, if you happen to still have full logs or an env where this reproduces, > it could help us. I don't sorry
Following discussion with Loic: This is a 5.8. with OCP 3.1 metrix. The advise to the customer is to move to 3.4. or 3.5.