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):
220.127.116.11, but seems to be present in all 5.10 builds
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';
"vm_or_template_id" and "vm_name" are not always filled, but the VM's name is still in the "vm_ems_ref"
These fields should be filled with the relevant 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.
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
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
I just tested in 18.104.22.168 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.
I.e. similar results as those reported in bug 1733384
New commit detected on ManageIQ/manageiq-providers-azure/ivanchuk:
Author: Daniel Berger <firstname.lastname@example.org>
AuthorDate: Fri Aug 9 10:02:42 2019 -0400
Commit: Daniel Berger <email@example.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)
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(-)
Verified in CFME 22.214.171.124, 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!
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