6:17 p.m.
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
Detailed Design :http://wiki.ovirt.org/wiki/Features/Design/DetailedExternalEvents
DR for this RFE will follow.
Thanks
Eli
10:55 a.m.
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?
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.
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?
other questions:
1. worth detailing all fields of the event which could be passed to this.
2. can an admin add events to entities they don't have permissions on
(I'm guessing yes, since admins aren't filtered from seeing all
entities, so implicitly, they have permission to all entities)
otherwise (if intent is to limit permisisons), an event is an action on
multiple entities, so for any field which is passed for the event
(vm_id, (vds)host_id, etc.), you'd need to check admin has
'AddExternalEvent' permission on.
the main reason i think doing permissions may hold merit is it will
allow to give this permission by default in more roles, rather than only
for superuser, which may make it more viable for UI plugins that would
try to leverage this.
3. REST API modeling for adding an event (is that a PUT on the event
collection, a POST)?
can it be done only on root events collection, or on events of entities
as well (taking the entity id from url, rather than as a parameter), etc.
11:40 p.m.
----- 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
> 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
other questions:
1. worth detailing all fields of the event which could be passed to
this.
Currently only the severity and the message text as stated in the doc.
2. can an admin add events to entities they don't have
permissions on
(I'm guessing yes, since admins aren't filtered from seeing all
entities, so implicitly, they have permission to all entities)
otherwise (if intent is to limit permisisons), an event is an action
on
multiple entities, so for any field which is passed for the event
(vm_id, (vds)host_id, etc.), you'd need to check admin has
'AddExternalEvent' permission on.
the main reason i think doing permissions may hold merit is it will
allow to give this permission by default in more roles, rather than
only
for superuser, which may make it more viable for UI plugins that
would
try to leverage this.
I am missing here something, it should be an external event, i.e. additional command
invoked by any plug-in
What is the relation to current events ?
3. REST API modeling for adding an event (is that a PUT on the event
collection, a POST)?
can it be done only on root events collection, or on events of
entities
as well (taking the entity id from url, rather than as a parameter),
etc.
Again, the only info I have from the requirement is to support an additional command.
The command invoker is responsible for the event text
It seems that you are talking about invoking our events from external plug-ins as well
9:10 a.m.
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???
not a must, just asking.
if an external system wants to inject an event the temperature of a host
is critical, its sounds more like an 'alert' to me than 'error'.
>
>> 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)
can't we separate the severity from the event id?
why are the two tightly coupled?
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
why should cleanup be different for internal and external events?
>
>> 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
>
> other questions:
> 1. worth detailing all fields of the event which could be passed to
> this.
Currently only the severity and the message text as stated in the doc.
I don't think this is good enough. idea is to be able to inject events
as they relate to entities (host,storage,vm,etc.)
> 2. can an admin add events to entities they don't have permissions on
> (I'm guessing yes, since admins aren't filtered from seeing all
> entities, so implicitly, they have permission to all entities)
> otherwise (if intent is to limit permisisons), an event is an action
> on
> multiple entities, so for any field which is passed for the event
> (vm_id, (vds)host_id, etc.), you'd need to check admin has
> 'AddExternalEvent' permission on.
>
> the main reason i think doing permissions may hold merit is it will
> allow to give this permission by default in more roles, rather than
> only
> for superuser, which may make it more viable for UI plugins that
> would
> try to leverage this.
I am missing here something, it should be an external event, i.e. additional command
invoked by any plug-in
What is the relation to current events ?
to current entities, not current events.
since the external events are about entities...
>
> 3. REST API modeling for adding an event (is that a PUT on the event
> collection, a POST)?
> can it be done only on root events collection, or on events of
> entities
> as well (taking the entity id from url, rather than as a parameter),
> etc.
>
Again, the only info I have from the requirement is to support an additional command.
The command invoker is responsible for the event text
my question was about the REST modeling of this new command (especially
as it is relevant only to the REST API, not to the UI).
not sure what you mean by 'event text' here.
It seems that you are talking about invoking our events from external
plug-ins as well
well, anything external. in any case they would be using the REST API
for this.
2:20 p.m.
----- 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: Sunday, November 11, 2012 9:10:32 AM
Subject: Re: [Engine-devel] [Design for 3.2 RFE] Adding support for external events
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???
not a must, just asking.
if an external system wants to inject an event the temperature of a
host
is critical, its sounds more like an 'alert' to me than 'error'.
OK,make sense , I will add it to the design
>
>>
>>> 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)
can't we separate the severity from the event id?
why are the two tightly coupled?
No we can't currently , we are assigning each AuditLogType a certain severity, so , I
will have to define here 4 for NORMAL , WARNING , ERROR and ALERT
> 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
why should cleanup be different for internal and external events?
I think that since those are external events ,it may clean up on a different period and
forced by the regular application event clean-up value
>
>
>>
>>> 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
>
>>
>> other questions:
>> 1. worth detailing all fields of the event which could be passed
>> to
>> this.
>
> Currently only the severity and the message text as stated in the
> doc.
I don't think this is good enough. idea is to be able to inject
events
as they relate to entities (host,storage,vm,etc.)
>
>> 2. can an admin add events to entities they don't have permissions
>> on
>> (I'm guessing yes, since admins aren't filtered from seeing all
>> entities, so implicitly, they have permission to all entities)
>> otherwise (if intent is to limit permisisons), an event is an
>> action
>> on
>> multiple entities, so for any field which is passed for the event
>> (vm_id, (vds)host_id, etc.), you'd need to check admin has
>> 'AddExternalEvent' permission on.
>>
>> the main reason i think doing permissions may hold merit is it
>> will
>> allow to give this permission by default in more roles, rather
>> than
>> only
>> for superuser, which may make it more viable for UI plugins that
>> would
>> try to leverage this.
>
>
> I am missing here something, it should be an external event, i.e.
> additional command invoked by any plug-in
> What is the relation to current events ?
to current entities, not current events.
since the external events are about entities...
How entities are passed to the engine?
Do we have a full use-case for that ?
>
>>
>> 3. REST API modeling for adding an event (is that a PUT on the
>> event
>> collection, a POST)?
>> can it be done only on root events collection, or on events of
>> entities
>> as well (taking the entity id from url, rather than as a
>> parameter),
>> etc.
>>
>
> Again, the only info I have from the requirement is to support an
> additional command.
> The command invoker is responsible for the event text
my question was about the REST modeling of this new command
(especially
as it is relevant only to the REST API, not to the UI).
not sure what you mean by 'event text' here.
> It seems that you are talking about invoking our events from
> external plug-ins as well
well, anything external. in any case they would be using the REST API
for this.
2:37 p.m.
On 11/11/2012 02:20 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: Sunday, November 11, 2012 9:10:32 AM
> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Adding support for external events
>
> 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???
>
> not a must, just asking.
> if an external system wants to inject an event the temperature of a
> host
> is critical, its sounds more like an 'alert' to me than 'error'.
OK,make sense , I will add it to the design
>
>>
>>>
>>>> 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)
>
> can't we separate the severity from the event id?
> why are the two tightly coupled?
No we can't currently , we are assigning each AuditLogType a certain severity, so , I
will have to define here 4 for NORMAL , WARNING , ERROR and ALERT
>
>> 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
>
> why should cleanup be different for internal and external events?
I think that since those are external events ,it may clean up on a different period and
forced by the regular application event clean-up value
>
>>
>>
>>>
>>>> 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
>>
>>>
>>> other questions:
>>> 1. worth detailing all fields of the event which could be passed
>>> to
>>> this.
>>
>> Currently only the severity and the message text as stated in the
>> doc.
>
> I don't think this is good enough. idea is to be able to inject
> events
> as they relate to entities (host,storage,vm,etc.)
>
>>
>>> 2. can an admin add events to entities they don't have permissions
>>> on
>>> (I'm guessing yes, since admins aren't filtered from seeing all
>>> entities, so implicitly, they have permission to all entities)
>>> otherwise (if intent is to limit permisisons), an event is an
>>> action
>>> on
>>> multiple entities, so for any field which is passed for the event
>>> (vm_id, (vds)host_id, etc.), you'd need to check admin has
>>> 'AddExternalEvent' permission on.
>>>
>>> the main reason i think doing permissions may hold merit is it
>>> will
>>> allow to give this permission by default in more roles, rather
>>> than
>>> only
>>> for superuser, which may make it more viable for UI plugins that
>>> would
>>> try to leverage this.
>>
>>
>> I am missing here something, it should be an external event, i.e.
>> additional command invoked by any plug-in
>> What is the relation to current events ?
>
> to current entities, not current events.
> since the external events are about entities...
How entities are passed to the engine?
Do we have a full use-case for that ?
an audit log event today can specify multiple entities (well, one of
each type) it is relevant to.
why wouldn't an external event be able to?
use case?
external host monitoring system to inject an event that a host fan has
malfunctioned.
external antivirus appliance scan to inject an event a vm has a virus.
etc.
there are two questions here:
1. API modeling wrt which action is "adding an event" (PUT on event
collection, or POST for an action). if allowing entities, than
probably entity is assumed from the action happening on the entity
events collection.
2. permission check
- inject with single entity - requires permission for this action on
the relevant entity). this permission could probably part of regular
roles?
- inject with multiple entities - need to check the permission for each
entity
- inject with no entity - requires system level permission to inject.
this by default would only be in super user role.
btw - all are the exact same single permission.
>
>>
>>>
>>> 3. REST API modeling for adding an event (is that a PUT on the
>>> event
>>> collection, a POST)?
>>> can it be done only on root events collection, or on events of
>>> entities
>>> as well (taking the entity id from url, rather than as a
>>> parameter),
>>> etc.
>>>
>>
>> Again, the only info I have from the requirement is to support an
>> additional command.
>> The command invoker is responsible for the event text
>
> my question was about the REST modeling of this new command
> (especially
> as it is relevant only to the REST API, not to the UI).
> not sure what you mean by 'event text' here.
>
>> It seems that you are talking about invoking our events from
>> external plug-ins as well
>
> well, anything external. in any case they would be using the REST API
> for this.
>
4:04 p.m.
----- 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: Sunday, November 11, 2012 2:37:34 PM
Subject: Re: [Engine-devel] [Design for 3.2 RFE] Adding support for external events
On 11/11/2012 02:20 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: Sunday, November 11, 2012 9:10:32 AM
>> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Adding support
>> for external events
>>
>> 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???
>>
>> not a must, just asking.
>> if an external system wants to inject an event the temperature of
>> a
>> host
>> is critical, its sounds more like an 'alert' to me than
'error'.
> OK,make sense , I will add it to the design
>>
>>>
>>>>
>>>>> 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)
>>
>> can't we separate the severity from the event id?
>> why are the two tightly coupled?
>
> No we can't currently , we are assigning each AuditLogType a
> certain severity, so , I will have to define here 4 for NORMAL ,
> WARNING , ERROR and ALERT
>
>>
>>> 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
>>
>> why should cleanup be different for internal and external events?
>
> I think that since those are external events ,it may clean up on a
> different period and forced by the regular application event
> clean-up value
>
>>
>>>
>>>
>>>>
>>>>> 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
>>>
>>>>
>>>> other questions:
>>>> 1. worth detailing all fields of the event which could be passed
>>>> to
>>>> this.
>>>
>>> Currently only the severity and the message text as stated in the
>>> doc.
>>
>> I don't think this is good enough. idea is to be able to inject
>> events
>> as they relate to entities (host,storage,vm,etc.)
>>
>>>
>>>> 2. can an admin add events to entities they don't have
>>>> permissions
>>>> on
>>>> (I'm guessing yes, since admins aren't filtered from seeing all
>>>> entities, so implicitly, they have permission to all entities)
>>>> otherwise (if intent is to limit permisisons), an event is an
>>>> action
>>>> on
>>>> multiple entities, so for any field which is passed for the
>>>> event
>>>> (vm_id, (vds)host_id, etc.), you'd need to check admin has
>>>> 'AddExternalEvent' permission on.
>>>>
>>>> the main reason i think doing permissions may hold merit is it
>>>> will
>>>> allow to give this permission by default in more roles, rather
>>>> than
>>>> only
>>>> for superuser, which may make it more viable for UI plugins that
>>>> would
>>>> try to leverage this.
>>>
>>>
>>> I am missing here something, it should be an external event, i.e.
>>> additional command invoked by any plug-in
>>> What is the relation to current events ?
>>
>> to current entities, not current events.
>> since the external events are about entities...
>
> How entities are passed to the engine?
> Do we have a full use-case for that ?
an audit log event today can specify multiple entities (well, one of
each type) it is relevant to.
why wouldn't an external event be able to?
use case?
external host monitoring system to inject an event that a host fan
has
malfunctioned.
external antivirus appliance scan to inject an event a vm has a
virus.
etc.
OK, got it now, thanks
there are two questions here:
1. API modeling wrt which action is "adding an event" (PUT on event
collection, or POST for an action). if allowing entities, than
probably entity is assumed from the action happening on the
entity
events collection.
I think it should be POST (new action/command)
2. permission check
- inject with single entity - requires permission for this action on
the relevant entity). this permission could probably part of
regular
roles?
- inject with multiple entities - need to check the permission for
each
entity
- inject with no entity - requires system level permission to inject.
this by default would only be in super user role.
btw - all are the exact same single permission.
Thanks
>
>>
>>>
>>>>
>>>> 3. REST API modeling for adding an event (is that a PUT on the
>>>> event
>>>> collection, a POST)?
>>>> can it be done only on root events collection, or on events of
>>>> entities
>>>> as well (taking the entity id from url, rather than as a
>>>> parameter),
>>>> etc.
>>>>
>>>
>>> Again, the only info I have from the requirement is to support an
>>> additional command.
>>> The command invoker is responsible for the event text
>>
>> my question was about the REST modeling of this new command
>> (especially
>> as it is relevant only to the REST API, not to the UI).
>> not sure what you mean by 'event text' here.
>>
>>> It seems that you are talking about invoking our events from
>>> external plug-ins as well
>>
>> well, anything external. in any case they would be using the REST
>> API
>> for this.
>>
9:50 a.m.
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
>> 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?
Y.
> other questions:
> 1. worth detailing all fields of the event which could be passed to
> this.
Currently only the severity and the message text as stated in the doc.
> 2. can an admin add events to entities they don't have permissions on
> (I'm guessing yes, since admins aren't filtered from seeing all
> entities, so implicitly, they have permission to all entities)
> otherwise (if intent is to limit permisisons), an event is an action
> on
> multiple entities, so for any field which is passed for the event
> (vm_id, (vds)host_id, etc.), you'd need to check admin has
> 'AddExternalEvent' permission on.
>
> the main reason i think doing permissions may hold merit is it will
> allow to give this permission by default in more roles, rather than
> only
> for superuser, which may make it more viable for UI plugins that
> would
> try to leverage this.
I am missing here something, it should be an external event, i.e. additional command
invoked by any plug-in
What is the relation to current events ?
> 3. REST API modeling for adding an event (is that a PUT on the event
> collection, a POST)?
> can it be done only on root events collection, or on events of
> entities
> as well (taking the entity id from url, rather than as a parameter),
> etc.
>
Again, the only info I have from the requirement is to support an additional command.
The command invoker is responsible for the event text
It seems that you are talking about invoking our events from external plug-ins as well
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
10:06 a.m.
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
>
>
>>> 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.
5:12 p.m.
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.
>>
>>
>>>> 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
6:18 p.m.
----- 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
>>>
>>>
>>>>> 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
7:04 p.m.
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.
(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
>
11:16 p.m.
----- 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
>>
4184
days inactive
4187
days old
12 comments
4 participants
participants (4)
-
Eli Mesika -
Itamar Heim -
Miki Kenneth -
Yaniv Kaul