Bug 1730819

Summary: Azure "virtualMachines_delete_EndRequest" event type is sometimes disassociated from a VM's name
Product: Red Hat CloudForms Management Engine Reporter: John Dupuy <jdupuy>
Component: ProvidersAssignee: Adam Grare <agrare>
Status: CLOSED CURRENTRELEASE QA Contact: John Dupuy <jdupuy>
Severity: medium Docs Contact: Red Hat CloudForms Documentation <cloudforms-docs>
Priority: medium    
Version: 5.10.7CC: dberger, jdupuy, jfrey, jhardy, obarenbo, simaishi
Target Milestone: GAKeywords: TestOnly, ZStream
Target Release: 5.11.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 5.11.0.19 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1733384 (view as bug list) Environment:
Last Closed: 2019-12-13 14:54:46 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: Bug
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: Azure Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1733384    

Description John Dupuy 2019-07-17 18:59:03 UTC
Description of problem:
When deleting an Azure instance, this results in the event "virtualMachines_delete_EndRequest" being received by CFME from Azure. About 50% of the time, the vm_name and vm_or_template_id will be NULL for this event. However, the vm_ems_ref will be populated, and will display the correct instance name. 

Version-Release number of selected component (if applicable):
5.10.7.1, but seems to be present in all 5.10 builds

How reproducible:
50%

Steps to Reproduce:
1. Add Azure to CFME
2. Provision an instance 
3. Delete the instance and wait about 10 min
4. Run the following query in the "vmdb_production" db:

select id, event_type, vm_or_template_id, vm_name, vm_ems_ref from event_streams where source='AZURE' and event_type='virtualMachines_delete_EndRequest';

Actual results:
"vm_or_template_id" and "vm_name" are not always filled, but the VM's name is still in the "vm_ems_ref"

Expected results:
These fields should be filled with the relevant info. 

Additional info:
The result of these fields not being filled means that the events won't appear on the timelines of the VM. 


This is likely related to BZ 1724312.

Comment 4 Adam Grare 2019-07-18 12:52:17 UTC
Hey Alex I think we talked about this and just need to set the vm name when an event is "reconnected" to events after an ems_refresh

Comment 5 Alexander Zagaynov 2019-07-24 15:00:41 UTC
John, if instance is deleted, there should not be a `VmOrTemplate` record in our database. Therefore we can not refer to `vm_or_template_id`, and we have no `vm_name`.
However, we can and do keep external reference, because we know it from Azure.

What about reconnection, Adam mentioned in the comment #4 - it is solved by https://github.com/ManageIQ/manageiq/pull/19031

Steps to reproduce (in dev env):
- evm should be stopped
- Run related MiQ's EventCatcher
- Create VM on Azure side
- We should see events for this VM in our databaseŠ± without internal vm reference and it's name, but with external vm reference
- We should not see this vm in our database, because refresh worker was not running
- Run refresh worker
- We should see that this event record now has vm name and internal reference
- We should see this vm in our database

Comment 12 John Dupuy 2019-08-01 14:00:33 UTC
I just tested in 5.11.0.17 and I am still not convinced this is fixed, seeing similar results as to when I originally reported the BZ after provisioning and deleting a VM 5 times.

http://pastebin.test.redhat.com/785244

I.e. similar results as those reported in bug 1733384

Comment 14 Satoe Imaishi 2019-08-09 22:17:29 UTC
New commit detected on ManageIQ/manageiq-providers-azure/ivanchuk:

https://github.com/ManageIQ/manageiq-providers-azure/commit/4bd7f16ca57774cde18a1315d820ef25f6d87797
commit 4bd7f16ca57774cde18a1315d820ef25f6d87797
Author:     Daniel Berger <djberg96>
AuthorDate: Fri Aug  9 10:02:42 2019 -0400
Commit:     Daniel Berger <djberg96>
CommitDate: Fri Aug  9 10:02:42 2019 -0400

    Set the vm_uid_ems in the event parser if it's a VM.

    Add check for vm_uid_ems in event parser specs.

    (cherry picked from commit fe5dc6364b7f98477d77cfc06b78fd0a3ed28ae1)

    Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1733384

 app/models/manageiq/providers/azure/cloud_manager/event_parser.rb | 2 +-
 spec/models/manageiq/providers/azure/cloud_manager/event_parser_spec.rb | 7 +-
 2 files changed, 6 insertions(+), 3 deletions(-)

Comment 15 John Dupuy 2019-08-15 15:20:32 UTC
Verified in CFME 5.11.0.19, I tested with by creating and deleting 5 VMs. The events were received every time (though sometimes out of order) and each of them was associated with the vm_name and vm_or_template_id. 

Thanks for all the work on this BZ!

Results:
vmdb_production=# select id, event_type, vm_name, vm_or_template_id, source from event_streams where event_type = 'virtualMachines_delete_EndRequest'; 
 id  |            event_type             |   vm_name    | vm_or_template_id | source 
-----+-----------------------------------+--------------+-------------------+--------
 317 | virtualMachines_delete_EndRequest | test-jdupuy0 |                84 | AZURE
 327 | virtualMachines_delete_EndRequest | test-jdupuy0 |                84 | AZURE
 329 | virtualMachines_delete_EndRequest | test-jdupuy1 |                85 | AZURE
 343 | virtualMachines_delete_EndRequest | test-jdupuy2 |                86 | AZURE
 356 | virtualMachines_delete_EndRequest | test-jdupuy1 |                85 | AZURE
 381 | virtualMachines_delete_EndRequest | test-jdupuy3 |                88 | AZURE
 390 | virtualMachines_delete_EndRequest | test-jdupuy2 |                86 | AZURE
 414 | virtualMachines_delete_EndRequest | test-jdupuy4 |                89 | AZURE