New commit detected on ManageIQ/manageiq-providers-openstack/hammer: https://github.com/ManageIQ/manageiq-providers-openstack/commit/6593995dcbb1c3f5dde573800740f35d0024bf77 commit 6593995dcbb1c3f5dde573800740f35d0024bf77 Author: Samuel Lucidi <mansam.edu> AuthorDate: Fri Mar 29 11:44:18 2019 -0400 Commit: Samuel Lucidi <mansam.edu> CommitDate: Fri Mar 29 11:44:18 2019 -0400 Merge pull request #457 from aufi/event_timezone_utc Parse OpenStack Event Timestamps as UTC (cherry picked from commit 715a5eda99bcfa62bb6ecbe340e1df149efc3f2f) Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1694190 lib/manageiq/providers/openstack/legacy/events/openstack_ceilometer_event_monitor.rb | 10 +- 1 file changed, 7 insertions(+), 3 deletions(-)
Verified! Tested and checked for SSH and VDDK transformation method of OSP and it is working! Verified on: 5.10.3.0.20190402144650_62f3960
We have tested this previously with QE's osp13 and it went well. Now we tried migration again with solution engineering's osp14 which gave us inventory refresh issue again. We waited for nearly 18min or so and then refresh inventory and then migration was successful. Setup information: Used lab vmware only Added osp with ssl-without-validation Added qe-conversion-host1 as a conversion hosts with inventory something like https://paste.fedoraproject.org/paste/HAnnYCWRsFOU4siSPlRu9A and thats it no other things are done. Found issue on: https://10.16.5.82/migration/plans Hence marking it failedQA.
Marek, can you look at it, please ?
Sure, can I get access to the OpenStack 14 deployment? CF appliance from Comment #4 doesn't contain OSP provider. (I use OSP14 on my dev setup which looked to be working)
@YTale, the appliance at https://10.16.5.82 is empty: no provider is configured, neither VMware, nor OpenStack. Did you change anything there ? Or has it been reprovisioned over the week-end ?
It re-provisioned for no reason, sorry again! :/ I'm deploying freshly appliance, going to reproduce issue on this and send you the IP.
I have added osp14 and vmware of sol engineering lab on https://10.8.197.155. Not able to proceed due to ems_ref error of BZ1694176. @Fabien, @Marek can you please check!
Events/refresh triggering seems to be correct there. We should propably search logs if there something pointing either to late event delivery or skip an event or some other issue..
Later after Comment #9, I migrated vm on https://10.16.5.95 where we did not found an issue and I'm confuse right now why this occurring randomly.
Marking it verified since not able to reproduce inventory issue. Thanks for help everyone.
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/RHSA-2019:0796
Seeing this issue again in 5.10.10.0.20190905201238_76e3ac6. Appliance : https://10.8.197.253 (solutions lab OSP) Appliance : https://10.8.198.47 (QE lab osp)
Note : There is no skip_event_history flag in 5.10 like 5.11 to set to true . https://bugzilla.redhat.com/show_bug.cgi?id=1692892#c32
Opened new BZ , closing this one.