Bug 1333467 - VMDB cluster instances being deleted in advance of hosts being disconnected and later reconnected to same named clusters
Summary: VMDB cluster instances being deleted in advance of hosts being disconnected a...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Providers
Version: 5.4.0
Hardware: x86_64
OS: Linux
high
high
Target Milestone: GA
: 5.5.4
Assignee: Adam Grare
QA Contact: Matouš Mojžíš
URL:
Whiteboard:
: 1333434 (view as bug list)
Depends On: 1329417
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-05-05 15:07 UTC by John Prause
Modified: 2019-10-10 12:03 UTC (History)
13 users (show)

Fixed In Version: 5.5.4.1
Doc Type: Bug Fix
Doc Text:
Previously, VMDB cluster entries were being logged as being deleted immediately before a set of hosts were being disconnected (not deleted). The hosts reconnected later (with same host id) and were reconnected to new cluster instances named the same as the ones deleted. However, the tags were lost in the process so provisioning was being impacted. This patch limits objects returned by initial waitForUpdatesEx. The initial call to waitForUpdatesEx returned every inventory item in one call. With large inventories this bumped up against the 2min HTTP timeout requiring a number of retries and an increasing timeout. The new WaitForUpdatesEx method allows the caller to specify a maximum number of objects to be returned by any one waitForUpdatesEx call, which allows paging through the initial inventory without needing to increase the timeout.
Clone Of: 1329417
Environment:
Last Closed: 2016-05-31 13:43:12 UTC
Category: ---
Cloudforms Team: ---
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:1101 0 normal SHIPPED_LIVE CFME 5.5.4 bug fixes and enhancement update 2016-05-31 17:40:10 UTC

Comment 3 Adam Grare 2016-05-09 17:29:03 UTC
*** Bug 1333434 has been marked as a duplicate of this bug. ***

Comment 4 CFME Bot 2016-05-09 17:47:00 UTC
New commit detected on cfme/5.5.z:
https://code.engineering.redhat.com/gerrit/gitweb?p=cfme.git;a=commitdiff;h=1d654d3235cc3bca1f5a6282d5f39ccc125cb72f

commit 1d654d3235cc3bca1f5a6282d5f39ccc125cb72f
Author:     Adam Grare <agrare>
AuthorDate: Mon Mar 28 09:27:14 2016 -0400
Commit:     Adam Grare <agrare>
CommitDate: Thu May 5 11:10:21 2016 -0400

    Limit objects returned by initial waitForUpdatesEx
    
    The initial call to waitForUpdatesEx will return every inventory
    item in one call, with very large inventories this can bump up
    against the 2min HTTP timeout requiring a number of retries and
    an increasing timeout.  The new WaitForUpdatesEx method allows
    the caller to specify a maximum number of objects to be returned
    by any one waitForUpdatesEx call, which allows us to page through
    the initial inventory without needing to increase the timeout.
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1333467

 app/models/miq_vim_broker_worker/runner.rb       |  2 +
 config/vmdb.tmpl.yml                             |  2 +
 gems/pending/VMwareWebService/DMiqVim.rb         |  3 +-
 gems/pending/VMwareWebService/MiqVimBroker.rb    | 20 +++++++-
 gems/pending/VMwareWebService/MiqVimUpdate.rb    | 59 ++++++++++++------------
 spec/models/miq_vim_broker_worker/runner_spec.rb |  2 +
 6 files changed, 56 insertions(+), 32 deletions(-)

Comment 5 CFME Bot 2016-05-09 17:47:06 UTC
New commit detected on cfme/5.5.z:
https://code.engineering.redhat.com/gerrit/gitweb?p=cfme.git;a=commitdiff;h=d390c6e354db9122130980c54f8f93b5b9f474d7

commit d390c6e354db9122130980c54f8f93b5b9f474d7
Merge: 2a7dcef 1d654d3
Author:     Greg Blomquist <gblomqui>
AuthorDate: Mon May 9 13:17:59 2016 -0400
Commit:     Greg Blomquist <gblomqui>
CommitDate: Mon May 9 13:17:59 2016 -0400

    Merge branch 'bz_1333467_vmware_truncated_inventory' into '5.5.z'
    
    Handle truncated inventory returned by initial waitForUpdatesEx
    
    This handles truncated inventory returned from the VMware WaitForUpdatesEx call.
    
    Clean cherry-pick of https://github.com/ManageIQ/manageiq/pull/7540
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1333467
    
    See merge request !927

 app/models/miq_vim_broker_worker/runner.rb       |  2 +
 config/vmdb.tmpl.yml                             |  2 +
 gems/pending/VMwareWebService/DMiqVim.rb         |  3 +-
 gems/pending/VMwareWebService/MiqVimBroker.rb    | 20 +++++++-
 gems/pending/VMwareWebService/MiqVimUpdate.rb    | 59 ++++++++++++------------
 spec/models/miq_vim_broker_worker/runner_spec.rb |  2 +
 6 files changed, 56 insertions(+), 32 deletions(-)

Comment 9 Matouš Mojžíš 2016-05-24 16:22:28 UTC
Verified in 5.5.4.2.
Added provider with 3000vms, set evm log to info. In log I saw only version 1.

Comment 11 errata-xmlrpc 2016-05-31 13:43:12 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/RHBA-2016:1101


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