Bug 1730819 - Azure "virtualMachines_delete_EndRequest" event type is sometimes disassociated from a VM's name
Summary: Azure "virtualMachines_delete_EndRequest" event type is sometimes disassociat...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Providers
Version: 5.10.7
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: GA
: 5.11.0
Assignee: Adam Grare
QA Contact: John Dupuy
Red Hat CloudForms Documentation
URL:
Whiteboard:
Depends On:
Blocks: 1733384
TreeView+ depends on / blocked
 
Reported: 2019-07-17 18:59 UTC by John Dupuy
Modified: 2019-12-13 14:54 UTC (History)
6 users (show)

Fixed In Version: 5.11.0.19
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1733384 (view as bug list)
Environment:
Last Closed: 2019-12-13 14:54:46 UTC
Category: Bug
Cloudforms Team: Azure
Target Upstream Version:


Attachments (Terms of Use)

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@gmail.com>
AuthorDate: Fri Aug  9 10:02:42 2019 -0400
Commit:     Daniel Berger <djberg96@gmail.com>
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


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