----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: "Eli Mesika" <emesika(a)redhat.com>
Cc: mkenneth(a)redhat.com, "engine-devel" <engine-devel(a)ovirt.org>
Sent: Sunday, November 11, 2012 7:04:21 PM
Subject: Re: [Engine-devel] [Design for 3.2 RFE] Adding support for external events
On 11/11/2012 06:18 PM, Eli Mesika wrote:
>
>
> ----- Original Message -----
>> From: "Miki Kenneth" <mkenneth(a)redhat.com>
>> To: "Itamar Heim" <iheim(a)redhat.com>
>> Cc: "engine-devel" <engine-devel(a)ovirt.org>
>> Sent: Sunday, November 11, 2012 5:12:23 PM
>> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Adding support
>> for external events
>>
>> On 11/11/2012 10:06 AM, Itamar Heim wrote:
>>> On 11/11/2012 09:50 AM, Yaniv Kaul wrote:
>>>> On 11/10/2012 11:40 PM, Eli Mesika wrote:
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Itamar Heim" <iheim(a)redhat.com>
>>>>>> To: "Eli Mesika" <emesika(a)redhat.com>
>>>>>> Cc: "engine-devel" <engine-devel(a)ovirt.org>,
"Einav Cohen"
>>>>>> <ecohen(a)redhat.com>, "Michael Pasternak"
>>>>>> <mpastern(a)redhat.com>
>>>>>> Sent: Friday, November 9, 2012 10:55:58 AM
>>>>>> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Adding
>>>>>> support
>>>>>> for
>>>>>> external events
>>>>>>
>>>>>> On 11/08/2012 05:17 PM, Eli Mesika wrote:
>>>>>>> Hi
>>>>>>>
>>>>>>> Please review , any comments are welcomed (please note that
>>>>>>> API
>>>>>>> section is still in TBD)
>>>>>>>
>>>>>>> RFE :https://bugzilla.redhat.com/show_bug.cgi?id=873223
>>>>>>> Requirements :
>>>>>>>
http://wiki.ovirt.org/wiki/Features/ExternalEvents
>>>>>>> Events are classified as NORMAL , WARNING or ERROR and UI
>>>>>>> will
>>>>>>> display different icon according to that.
>>>>>> any reason to not allow external ALERTs?
>>>>> Currently we are using ALERTS only for PM events, do we have to
>>>>> allow
>>>>> displaying external Alerts in the Alerts TAB as well???
>>>>>
>>>>>>> Detailed Design
>>>>>>>
:http://wiki.ovirt.org/wiki/Features/Design/DetailedExternalEvents
>>>>>>> Adding is_external boolean field to audit_log with a
default
>>>>>>> value
>>>>>>> of false
>>>>>> hmmm, i'm not sure it makes sense to inject any event, just
>>>>>> flagging
>>>>>> it
>>>>>> as external.
>>>>>> why not just add a new AuditLogType of 'External' (i.e.,
just
>>>>>> another
>>>>>> event id?
>>>>>> it is easy enough to search for it, etc.
>>>>> We are adding not one AuditLogType rather , it will be 3 or 4
>>>>> (depends
>>>>> on we support also Alerts)
>>>>> The additional is_external is defaulted to false , so ,
>>>>> existing
>>>>> code
>>>>> is not influenced
>>>>> I think that in the search it will be simpler to refer to
>>>>> is_external
>>>>> rather to the 3 or 4 specific types
>>>>> Also , cleanup of old external events should use this column
>> regarding the clean-up events/alerts, is that possible while we
>> are
>> on
>> the subject?
>> It would be nice to indicate that alert was viewed and
>> acknowledged
>> and
>> we can filter it out of the tab.
>
> I think I should Support ALERT_ON and ALERT_OFF for that ...
> So, ALERT_ON will add that to the tab and ALERT_OFF will remove it
I think the more important thing (and generic to events as well) is
for
someone to flag the event/alert as owned/being handled by themselves,
commenting on what they did/are doing, etc.
not sure why alert should have an off mode, since iirc, alerts are
automatically cleaned when their root issue is solved.
Up to now, we had used Alerts only for PM , so , if for example we have no PM configured
on a Host , we will got an Alert that will be deleted (from audit_log table) when we
successfully configurer and tested PM on that Host.
So, in the case events , they really stay in DB until they become OLD and the clean-up
mechanism removes them, but , in Alerts , I believe that we should give an option to
remove and Alert or create the Alert with a deprecation time and remove it when this time
is passed...
(if anything, you would want to have an 'ignore alert' action
by an
admin (for X days/forever)
>
>>>>>
>>>>>
>>>>>>> New command is exposed currently only to SuperUser
>>>>>> I assume you mean there is a new permission, which by default
>>>>>> is
>>>>>> added
>>>>>> only to superuser role, and admin can add it to other custom
>>>>>> roles?
>>>>>> I also assume this is only relevant to admin users, not to
>>>>>> user
>>>>>> roles?
>>>>> Yes
>>>>
>>>> What's the protection against LDAP injection, SQL injection,
>>>> Javascript
>>>> injection ... ?
>>>> How do we sanitize the input of the event?
>>>>
>>>> Regardless, what about localization? Can the plugin know in
>>>> which
>>>> language it should inject the event?
>>>
>>> audit log is not localized at this point.
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel(a)ovirt.org
>>>
http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel(a)ovirt.org
>>
http://lists.ovirt.org/mailman/listinfo/engine-devel
>>