Ok, makes sense.
Regarding the vitrage_alarm_type: it will be usable only if there are a few
alarm types that are used by most datasources. Otherwise it might be just as
verbose as the name, IMO.
Anyway, you are welcome to propose a blueprint so we can discuss all details
there.
Best
I am thinking that alarm suppression would be per-tenant.
Yeah i am liking the second suggestion, as well, wrt specification of
suppressed alarms to be based on { vitrage_type & ‘regexp’ }.
Only other reason for introducing vitrage_alarm_type property is perhaps a
‘usability’ type reason
i.e.
Hi Greg,
First, I think that supporting alarm suppression in Vitrage is a very good idea.
One question that I have is: I understand that you plan to support it both in
the UI and in the CLI. Do you want to the suppression to be per-user?
per-tenant? global?
Regarding adding
Thinking about this more ...
· Any thoughts on adding a ‘vitrage_alarm_type (enum or short string)’
as a mechanism to identify the general type of problem or alarm being reported
in order to address this ?
ocould be an optional field
obut we’d display in the alarm list
oand
Hey,
I am interested in getting some feedback on a proposed blueprint for Vitrage.
BLUEPRINT:
TITLE: Add the ability to ‘suppress’ alarms by Alarm Type and/or Resource
When managing a cloud, there are situations where a particular alarm or a set
of alarms from a particular resource are
