Description of problem: ----------------------- My appliance is managing vSphere 6 and vSphere 65.I first added the vSphere 6 provider and then added the vSphere 65 provider.The initial refresh failed. When I manually refreshed the provider by clicking 'Configuration' and then clicking Refresh Relationships and Power Stated, the refresh succeeded. On a second appliance, I changed the order in which the two providers are added and the result was the same. Version-Release number of selected component (if applicable): -------------------------- 5.8.0.9 (This issue probably occurs in earlier versions as well). How reproducible: ---------------- Always Steps to Reproduce: ------------------- 1.Add a VMware provider to CFME 2.Add a second VMWare provider to CFME. Actual results: --------------- Full refresh of second VMware provider fails Expected results: ----------------- Full refresh of second VMware provider should succeed. Additional info: ----------------
Nandini I don't see any errors and if I run a refresh manually on your appliance for your second EMS it succeeds. Can you please attach a traceback from the logs when it failed?
There are no errors in the log.Manual refresh does succeed, but I'd like to know why the refresh doesn't succeed upon adding the second provider. After the second provider was added, the 'Last Refresh' field showed 'Never' in the summary page until a manual refresh was done.As a result, the VM count, host count remained zero until the manual refresh was done.
I confirmed on 5.4 that when adding the second VMware provider a refresh is not automatically started so this is not a regression. The problem is that while most RefreshWorkers run a refresh when they start up (https://github.com/ManageIQ/manageiq/blob/master/app/models/manageiq/providers/base_manager/refresh_worker/runner.rb#L16-L19), the VMware one does not (https://github.com/ManageIQ/manageiq-providers-vmware/blob/master/app/models/manageiq/providers/vmware/infra_manager/refresh_worker/runner.rb#L4-L7) because the MiqVimBrokerWorker does that after it finishes priming the ems cache (https://github.com/ManageIQ/manageiq/blob/master/app/models/miq_vim_broker_worker/runner.rb#L116-L121)
I should note that this is only an issue after adding a provider the first time, the scheduled refresh will run normally and after a reboot a full refresh will be queued on startup as expected.
https://github.com/ManageIQ/manageiq-providers-vmware/pull/41
New commit detected on ManageIQ/manageiq-providers-vmware/master: https://github.com/ManageIQ/manageiq-providers-vmware/commit/816a3634009ce87577f65bc8d540bbbb5e03aa1c commit 816a3634009ce87577f65bc8d540bbbb5e03aa1c Author: Adam Grare <agrare> AuthorDate: Mon Apr 17 13:55:57 2017 -0400 Commit: Adam Grare <agrare> CommitDate: Mon Apr 17 15:42:14 2017 -0400 Queue initial refresh if the Broker is available If the MiqVimBrokerWorker is starting up then it will queue a refresh when it finishes priming the cache. If the broker is already running when the RefreshWorker starts then we need to queue our own initial refresh. https://bugzilla.redhat.com/show_bug.cgi?id=1439387 .../manageiq/providers/vmware/infra_manager/refresh_worker/runner.rb | 4 ++++ 1 file changed, 4 insertions(+)
Re-opening due to unintended consequence noted in https://bugzilla.redhat.com/show_bug.cgi?id=1469198 This patch was backed out in https://github.com/ManageIQ/manageiq-providers-vmware/pull/75#event-1182127222
*** Bug 1518385 has been marked as a duplicate of this bug. ***
This depends on some core refactoring (i.e. moving the DMiqVim connection out of the VimBrokerWorker and into the per-ems RefreshWorker) so setting to XL
*** Bug 1573490 has been marked as a duplicate of this bug. ***
Adam scoped this as XL, and this particular issue is an edge case with a workaround (manual refresh). If necessary, we can doc this issue.
We have removed the worker restart_interval from core so we are able to implement this now
https://github.com/ManageIQ/manageiq-providers-vmware/pull/414
New commit detected on ManageIQ/manageiq-providers-vmware/master: https://github.com/ManageIQ/manageiq-providers-vmware/commit/0acf5aa8bf66f61f66ffeeae84ff73b138e72f9b commit 0acf5aa8bf66f61f66ffeeae84ff73b138e72f9b Author: Adam Grare <agrare> AuthorDate: Fri Jul 19 14:02:35 2019 -0400 Commit: Adam Grare <agrare> CommitDate: Fri Jul 19 14:02:35 2019 -0400 Let the RefreshWorker queue the first full refresh Move VMware more in line with the other providers by allowing the RefreshWorker to queue the first full when it starts up. This used to be done by the VimBrokerWorker because the RefreshWorkers restarted every 2 hours. Now that https://github.com/ManageIQ/manageiq/pull/19010 does restart the refresh_worker every 2 hours we can go back to just handling this in the RefreshWorker. Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1439387 Fixes https://github.com/ManageIQ/manageiq/issues/14813 app/models/manageiq/providers/vmware/infra_manager/refresh_worker/runner.rb | 5 - app/models/miq_vim_broker_worker/runner.rb | 7 - spec/models/miq_vim_broker_worker/runner_spec.rb | 23 - 3 files changed, 35 deletions(-)
New commit detected on ManageIQ/manageiq-providers-vmware/ivanchuk: https://github.com/ManageIQ/manageiq-providers-vmware/commit/992757a1556dc781fc712da375e9dddbf3ba7c58 commit 992757a1556dc781fc712da375e9dddbf3ba7c58 Author: Gregg Tanzillo <gtanzill> AuthorDate: Fri Aug 2 09:28:28 2019 -0400 Commit: Gregg Tanzillo <gtanzill> CommitDate: Fri Aug 2 09:28:28 2019 -0400 Merge pull request #414 from agrare/bz_1439387_queue_refresh_when_refresh_worker_starts Let the RefreshWorker queue the first full refresh (cherry picked from commit 1822f675f176ce135915327f59c3c4676ff46c81) https://bugzilla.redhat.com/show_bug.cgi?id=1439387 app/models/manageiq/providers/vmware/infra_manager/refresh_worker/runner.rb | 5 - app/models/miq_vim_broker_worker/runner.rb | 7 - spec/models/miq_vim_broker_worker/runner_spec.rb | 23 - 3 files changed, 35 deletions(-)
Verified on 5.11.0.19