Vitrage

Inconsistent resource_id property for different alarm types

Bug #1747895 reported by Ifat Afek on 2018-02-07

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	Vitrage	Triaged	Medium	Unassigned

Bug Description

On every alarm we have a vitrage_resource_id property with the vitrage_id of the resource the alarm is on. This works well from the API level through the graph and to the notifiers.

*In addition*, some alarm types define a RESOURCE_ID property as the id of the resource the alarm is on. This is not consistent between different alarm types:

- For Zabbix it is the *id* of the resource (e.g. the host name)
- For deduced alarms it is the *vitrage_id* of the resource
- Doctor alarms don't define it

Since this property is returned by vitrage topology show, it has to be consistent. Another issue to consider is that Vitrage should add properties only if their names start with vitrage_. And for id, we already have the vitrage_resource_id.

Possible solutions for vitrage deduced alarms:
1. Delete the creation of resource_id property
2. Set resource_id to be the id of the resource (and not the vitrage id)

#1 is probably better, but we should make sure nobody is using the resource_id at this point.

A related bug, specific for SNMP notifier, is that in SnmpNotifier._parse_alarm_data() the (wrong) RESOURCE_ID property sometimes overwrites the (right) property that is created on the fly as "RESOURCE_" + "ID".