Bug 1165305 - Openstack inventory collection fails with missing instances
Summary: Openstack inventory collection fails with missing instances
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Insight
Version: 5.3.0
Hardware: All
OS: All
Target Milestone: GA
: 5.3.2
Assignee: Greg Blomquist
QA Contact: Dave Johnson
: 1166282 1166295 (view as bug list)
Depends On:
Blocks: 1139277 1166282
TreeView+ depends on / blocked
Reported: 2014-11-18 19:26 UTC by Josh Carter
Modified: 2019-03-22 07:24 UTC (History)
8 users (show)

Fixed In Version: 5.3.2
Doc Type: Bug Fix
Doc Text:
In the earlier version of CloudForms Management Engine, the Open Stack inventory collection code produced an error when a volume attached to an instance was not visible in the tenants associated with the OpenStack user account. This issue was fixed by recognising this as a valid condition and logging a message that the volume could not be accessed, instead of generating an error. The error is no longer generated in the new version of CloudForms Management Engine, although the volume's inventory data remains uncollected and the link to the instance is not set.
Clone Of:
: 1166282 (view as bug list)
Last Closed: 2015-01-14 19:43:37 UTC
Category: ---
Cloudforms Team: ---
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:0028 0 normal SHIPPED_LIVE Important: cfme security, bug fix, and enhancement update 2015-01-15 00:41:27 UTC

Description Josh Carter 2014-11-18 19:26:54 UTC
Description of problem:

Cloudforms is unable to collect inventory for a openstack environment that has ~7 missing instances. 

[----] E, [2014-11-17T21:55:10.478421 #25433:924014] ERROR -- : excon.error     #<Excon::Errors::Unauthorized: Expected([200, 204]) <=> Actual(401 Unauthorized)
  response => #<Excon::Response:0x00000007194cc0 @data={:body=>"{\"error\": {\"message\": \"The request you have made requires authentication.\", \"code\": 401, \"title\": \"Unauthorized\"}}", :headers=>{"Vary"=>"X-Auth-Token", "Content-Type"=>"application/json", "Conte
nt-Length"=>"114", "Date"=>"Mon, 17 Nov 2014 21:55:26 GMT"}, :status=>401, :remote_ip=>""}, @body="{\"error\": {\"message\": \"The request you have made requires authentication.\", \"code\": 401, \"title\": \"Unauthorized\"}}", @headers={"Vary"=>"X-Auth-Toke
n", "Content-Type"=>"application/json", "Content-Length"=>"114", "Date"=>"Mon, 17 Nov 2014 21:55:26 GMT"}, @status=401, @remote_ip="">>

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

How reproducible: n/a

Steps to Reproduce:
1. n/a

Actual results:

Expected results:

Additional info:

Comment 2 Greg Blomquist 2014-12-02 02:15:06 UTC
Fix is in this upstream patch: https://github.com/ManageIQ/manageiq/commit/22bccfcd2cd2cc1e3a5bc383329b1ba9972e245f

Need to separate out the changes in #parse_volume and patch in 5.3.z.

Comment 3 CFME Bot 2014-12-04 21:36:01 UTC
New commit detected on cfme/5.3.z:

commit 7c94e2ec66d92751e96646092fa4b2e30debdaf6
Author:     Greg Blomquist <gblomqui@redhat.com>
AuthorDate: Thu Dec 4 15:58:46 2014 -0500
Commit:     Greg Blomquist <gblomqui@redhat.com>
CommitDate: Thu Dec 4 16:32:36 2014 -0500

    Handle openstack inventory case where volume not accessible
    There can be cases in Openstack Inventory collection when a volume that's
    attached to an instance is not visible in the tenants associated with the
    OpenStack user account.
    In this case, trying to dereference the data causes a Nil Reference error.
    Now, the code will simply log that it cannot access the volume and leave the
    volume's inventory data uncollected and the linkage to the instance unset.
    This was fixed upstream as part of PR 681.
    The original upstream patch can be found in commit: 22bccf

 vmdb/app/models/ems_refresh/parsers/openstack.rb | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

Comment 4 Greg Blomquist 2014-12-04 21:36:51 UTC
*** Bug 1166282 has been marked as a duplicate of this bug. ***

Comment 5 Josh Carter 2014-12-08 15:07:39 UTC
*** Bug 1166295 has been marked as a duplicate of this bug. ***

Comment 8 Greg Blomquist 2015-01-08 13:42:48 UTC

can you take a crack at explaining how the customer got into the state of having instances in one tenant and volumes in another?

My guess is that they associated the volumes to the instances, and then later moved the volumes or instances to another tenant.  In fact, I sort of remember something about this case where the customer was moving instances around, maybe?

Comment 10 Nandini Chandra 2015-01-08 18:30:30 UTC
Unable to reproduce this issue.

Customer(from case # 01284590) has verified that the fix provided fixes the issue in their setup.Marking the BZ as verified.

Comment 12 errata-xmlrpc 2015-01-14 19:43:37 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.


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