[Engine-devel] [Design for 3.2 RFE] Adding support for external events

Itamar Heim iheim at redhat.com
Sun Nov 11 08:06:19 UTC 2012


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 at redhat.com>
>>> To: "Eli Mesika" <emesika at redhat.com>
>>> Cc: "engine-devel" <engine-devel at ovirt.org>, "Einav Cohen"
>>> <ecohen at redhat.com>, "Michael Pasternak"
>>> <mpastern at 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
>>
>>
>>>> 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.



More information about the Devel mailing list