[Engine-devel] Design review summary for 3.2 - adding support for External Events
Hi Eli, I've perused the design and it looks very good for the purpose of adding events to the log as back end tasks on the NetApp VSC are started and complete. I do have one question. As part of the new UI plugin framework that Vojtech is working on he added the capability to retrieve a session ID that will be used outside of the oVirt engine to invoke REST API calls. I'm assuming this session would have the same role as the user that is currently logged in. According to the event log design, only the Super user will have permissions to add events by default. This would mean that if anyone other than the super user is logged in and performing any tasks through the NetApp plugin, the server side of the VSC will likely not be able to log events. This could be confusing for users as sometimes they see events showing up giving them information on the task progress and sometimes they don't depending on the role logged in. Would it make sense to allow all roles to log events by default? I'm not sure what security problems would arise given that it is just a log and they would be tagged as external events. -Chris -----Original Message----- From: engine-devel-bounces@ovirt.org [mailto:engine-devel-bounces@ovirt.org] On Behalf Of Eli Mesika Sent: Monday, November 19, 2012 7:24 AM To: engine-devel Subject: [Engine-devel] Design review summary for 3.2 - adding support for External Events Discussion : http://wiki.ovirt.org/wiki/Talk:ExternalEvents Updated Design : http://wiki.ovirt.org/wiki/Features/Design/DetailedExternalEvents#Future_dir... _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Hi Chris,
As part of the new UI plugin framework that Vojtech is working on he added the capability to retrieve a session ID that will be used outside of the oVirt engine to invoke REST API calls. I'm assuming this session would have the same role as the user that is currently logged in.
This is correct. UI plugin infrastructure acquires Engine REST API session using credentials of the user that logs into WebAdmin UI. Vojtech ----- Original Message ----- From: "Christopher Morrissey" <Christopher.Morrissey@netapp.com> To: "Eli Mesika" <emesika@redhat.com>, "engine-devel" <engine-devel@ovirt.org> Sent: Monday, November 19, 2012 3:50:34 PM Subject: Re: [Engine-devel] Design review summary for 3.2 - adding support for External Events Hi Eli, I've perused the design and it looks very good for the purpose of adding events to the log as back end tasks on the NetApp VSC are started and complete. I do have one question. As part of the new UI plugin framework that Vojtech is working on he added the capability to retrieve a session ID that will be used outside of the oVirt engine to invoke REST API calls. I'm assuming this session would have the same role as the user that is currently logged in. According to the event log design, only the Super user will have permissions to add events by default. This would mean that if anyone other than the super user is logged in and performing any tasks through the NetApp plugin, the server side of the VSC will likely not be able to log events. This could be confusing for users as sometimes they see events showing up giving them information on the task progress and sometimes they don't depending on the role logged in. Would it make sense to allow all roles to log events by default? I'm not sure what security problems would arise given that it is just a log and they would be tagged as external events. -Chris -----Original Message----- From: engine-devel-bounces@ovirt.org [mailto:engine-devel-bounces@ovirt.org] On Behalf Of Eli Mesika Sent: Monday, November 19, 2012 7:24 AM To: engine-devel Subject: [Engine-devel] Design review summary for 3.2 - adding support for External Events Discussion : http://wiki.ovirt.org/wiki/Talk:ExternalEvents Updated Design : http://wiki.ovirt.org/wiki/Features/Design/DetailedExternalEvents#Future_dir... _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
From: "Christopher Morrissey" <Christopher.Morrissey@netapp.com> To: "Eli Mesika" <emesika@redhat.com>, "engine-devel" <engine-devel@ovirt.org> Sent: Monday, November 19, 2012 4:50:34 PM Subject: RE: [Engine-devel] Design review summary for 3.2 - adding support for External Events
Hi Eli,
I've perused the design and it looks very good for the purpose of adding events to the log as back end tasks on the NetApp VSC are started and complete.
I do have one question. As part of the new UI plugin framework that Vojtech is working on he added the capability to retrieve a session ID that will be used outside of the oVirt engine to invoke REST API calls. I'm assuming this session would have the same role as the user that is currently logged in.
According to the event log design, only the Super user will have permissions to add events by default. This would mean that if anyone other than the super user is logged in and performing any tasks through the NetApp plugin, the server side of the VSC will likely not be able to log events. This could be confusing for users as sometimes they see events showing up giving them information on the task progress and sometimes they don't depending on the role logged in.
Would it make sense to allow all roles to log events by default? I'm not sure what security problems would arise given that it is just a log and they would be tagged as external events.
Hi Christopher, our security model implies a black-list, so, I don;t think this is possible But still, a super-user can of course give the permission to add new events to all Roles in the system and you will have the same result. Does that make sense ?
-Chris
-----Original Message----- From: engine-devel-bounces@ovirt.org [mailto:engine-devel-bounces@ovirt.org] On Behalf Of Eli Mesika Sent: Monday, November 19, 2012 7:24 AM To: engine-devel Subject: [Engine-devel] Design review summary for 3.2 - adding support for External Events
Discussion : http://wiki.ovirt.org/wiki/Talk:ExternalEvents Updated Design : http://wiki.ovirt.org/wiki/Features/Design/DetailedExternalEvents#Future_dir... _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
From: "Eli Mesika" <emesika@redhat.com> To: "Christopher Morrissey" <Christopher.Morrissey@netapp.com> Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Monday, November 19, 2012 11:09:32 PM Subject: Re: [Engine-devel] Design review summary for 3.2 - adding support for External Events
----- Original Message -----
From: "Christopher Morrissey" <Christopher.Morrissey@netapp.com> To: "Eli Mesika" <emesika@redhat.com>, "engine-devel" <engine-devel@ovirt.org> Sent: Monday, November 19, 2012 4:50:34 PM Subject: RE: [Engine-devel] Design review summary for 3.2 - adding support for External Events
Hi Eli,
I've perused the design and it looks very good for the purpose of adding events to the log as back end tasks on the NetApp VSC are started and complete.
I do have one question. As part of the new UI plugin framework that Vojtech is working on he added the capability to retrieve a session ID that will be used outside of the oVirt engine to invoke REST API calls. I'm assuming this session would have the same role as the user that is currently logged in.
According to the event log design, only the Super user will have permissions to add events by default. This would mean that if anyone other than the super user is logged in and performing any tasks through the NetApp plugin, the server side of the VSC will likely not be able to log events. This could be confusing for users as sometimes they see events showing up giving them information on the task progress and sometimes they don't depending on the role logged in.
Would it make sense to allow all roles to log events by default? I'm not sure what security problems would arise given that it is just a log and they would be tagged as external events.
Hi Christopher, our security model implies a black-list,
oops, I meant white-list of course .... so, I don;t
think this is possible But still, a super-user can of course give the permission to add new events to all Roles in the system and you will have the same result. Does that make sense ?
-Chris
-----Original Message----- From: engine-devel-bounces@ovirt.org [mailto:engine-devel-bounces@ovirt.org] On Behalf Of Eli Mesika Sent: Monday, November 19, 2012 7:24 AM To: engine-devel Subject: [Engine-devel] Design review summary for 3.2 - adding support for External Events
Discussion : http://wiki.ovirt.org/wiki/Talk:ExternalEvents Updated Design : http://wiki.ovirt.org/wiki/Features/Design/DetailedExternalEvents#Future_dir... _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
-Chris
-----Original Message----- From: Eli Mesika [mailto:emesika@redhat.com] Sent: Monday, November 19, 2012 11:16 PM To: Morrissey, Christopher Cc: engine-devel Subject: Re: [Engine-devel] Design review summary for 3.2 - adding support for External Events
----- Original Message -----
From: "Eli Mesika" <emesika@redhat.com> To: "Christopher Morrissey" <Christopher.Morrissey@netapp.com> Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Monday, November 19, 2012 11:09:32 PM Subject: Re: [Engine-devel] Design review summary for 3.2 - adding support for External Events
----- Original Message -----
From: "Christopher Morrissey" <Christopher.Morrissey@netapp.com> To: "Eli Mesika" <emesika@redhat.com>, "engine-devel" <engine-devel@ovirt.org> Sent: Monday, November 19, 2012 4:50:34 PM Subject: RE: [Engine-devel] Design review summary for 3.2 - adding support for External Events
Hi Eli,
I've perused the design and it looks very good for the purpose of adding events to the log as back end tasks on the NetApp VSC are started and complete.
I do have one question. As part of the new UI plugin framework that Vojtech is working on he added the capability to retrieve a session ID that will be used outside of the oVirt engine to invoke REST API calls. I'm assuming this session would have the same role as the user that is currently logged in.
According to the event log design, only the Super user will have permissions to add events by default. This would mean that if anyone other than the super user is logged in and performing any tasks through the NetApp plugin, the server side of the VSC will likely not be able to log events. This could be confusing for users as sometimes they see events showing up giving them information on the task progress and sometimes they don't depending on the role logged in.
Would it make sense to allow all roles to log events by default? I'm not sure what security problems would arise given that it is just a log and they would be tagged as external events.
Hi Christopher, our security model implies a black-list,
oops, I meant white-list of course ....
That's what I figured. :)
so, I don;t
think this is possible But still, a super-user can of course give the permission to add new events to all Roles in the system and you will have the same result. Does that make sense ?
That does make sense. We'll likely just try to use the API to log events when starting a task and if we receive an error we can bubble that up to the user letting them know that they need to either get the right permission or accept that they won't get messages in the oVirt log while the task completes.
-Chris
-----Original Message----- From: engine-devel-bounces@ovirt.org [mailto:engine-devel-bounces@ovirt.org] On Behalf Of Eli Mesika Sent: Monday, November 19, 2012 7:24 AM To: engine-devel Subject: [Engine-devel] Design review summary for 3.2 - adding support for External Events
Discussion : http://wiki.ovirt.org/wiki/Talk:ExternalEvents Updated Design : http://wiki.ovirt.org/wiki/Features/Design/DetailedExternalEvents#Fu ture_directions
Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 11/20/2012 04:07 PM, Morrissey, Christopher wrote: ...
Hi Eli,
I've perused the design and it looks very good for the purpose of adding events to the log as back end tasks on the NetApp VSC are started and complete.
I do have one question. As part of the new UI plugin framework that Vojtech is working on he added the capability to retrieve a session ID that will be used outside of the oVirt engine to invoke REST API calls. I'm assuming this session would have the same role as the user that is currently logged in.
According to the event log design, only the Super user will have permissions to add events by default. This would mean that if anyone other than the super user is logged in and performing any tasks through the NetApp plugin, the server side of the VSC will likely not be able to log events. This could be confusing for users as sometimes they see events showing up giving them information on the task progress and sometimes they don't depending on the role logged in.
Would it make sense to allow all roles to log events by default? I'm not sure what security problems would arise given that it is just a log and they would be tagged as external events.
Hi Christopher, our security model implies a black-list,
oops, I meant white-list of course ....
That's what I figured. :)
so, I don;t
think this is possible But still, a super-user can of course give the permission to add new events to all Roles in the system and you will have the same result. Does that make sense ?
That does make sense. We'll likely just try to use the API to log events when starting a task and if we receive an error we can bubble that up to the user letting them know that they need to either get the right permission or accept that they won't get messages in the oVirt log while the task completes.
Eli - not that the design includes checking for permissions on objects, why wouldn't we add this permission (ActionGroup) to other admin roles as well? this is only for admin roles, not user roles. what's the risk in allowing admins to inject external events?
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Christopher Morrissey" <Christopher.Morrissey@netapp.com> Cc: "Eli Mesika" <emesika@redhat.com>, "engine-devel" <engine-devel@ovirt.org> Sent: Thursday, November 22, 2012 8:35:56 AM Subject: Re: [Engine-devel] Design review summary for 3.2 - adding support for External Events
On 11/20/2012 04:07 PM, Morrissey, Christopher wrote: ...
Hi Eli,
I've perused the design and it looks very good for the purpose of adding events to the log as back end tasks on the NetApp VSC are started and complete.
I do have one question. As part of the new UI plugin framework that Vojtech is working on he added the capability to retrieve a session ID that will be used outside of the oVirt engine to invoke REST API calls. I'm assuming this session would have the same role as the user that is currently logged in.
According to the event log design, only the Super user will have permissions to add events by default. This would mean that if anyone other than the super user is logged in and performing any tasks through the NetApp plugin, the server side of the VSC will likely not be able to log events. This could be confusing for users as sometimes they see events showing up giving them information on the task progress and sometimes they don't depending on the role logged in.
Would it make sense to allow all roles to log events by default? I'm not sure what security problems would arise given that it is just a log and they would be tagged as external events.
Hi Christopher, our security model implies a black-list,
oops, I meant white-list of course ....
That's what I figured. :)
so, I don;t
think this is possible But still, a super-user can of course give the permission to add new events to all Roles in the system and you will have the same result. Does that make sense ?
That does make sense. We'll likely just try to use the API to log events when starting a task and if we receive an error we can bubble that up to the user letting them know that they need to either get the right permission or accept that they won't get messages in the oVirt log while the task completes.
Eli - not that the design includes checking for permissions on objects, why wouldn't we add this permission (ActionGroup) to other admin roles as well?
You mean in DB upgrade , right ?
this is only for admin roles, not user roles. what's the risk in allowing admins to inject external events?
IIUC , you are right , no risk
On 11/23/2012 01:10 AM, Eli Mesika wrote:
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Christopher Morrissey" <Christopher.Morrissey@netapp.com> Cc: "Eli Mesika" <emesika@redhat.com>, "engine-devel" <engine-devel@ovirt.org> Sent: Thursday, November 22, 2012 8:35:56 AM Subject: Re: [Engine-devel] Design review summary for 3.2 - adding support for External Events
On 11/20/2012 04:07 PM, Morrissey, Christopher wrote: ...
Hi Eli,
I've perused the design and it looks very good for the purpose of adding events to the log as back end tasks on the NetApp VSC are started and complete.
I do have one question. As part of the new UI plugin framework that Vojtech is working on he added the capability to retrieve a session ID that will be used outside of the oVirt engine to invoke REST API calls. I'm assuming this session would have the same role as the user that is currently logged in.
According to the event log design, only the Super user will have permissions to add events by default. This would mean that if anyone other than the super user is logged in and performing any tasks through the NetApp plugin, the server side of the VSC will likely not be able to log events. This could be confusing for users as sometimes they see events showing up giving them information on the task progress and sometimes they don't depending on the role logged in.
Would it make sense to allow all roles to log events by default? I'm not sure what security problems would arise given that it is just a log and they would be tagged as external events.
Hi Christopher, our security model implies a black-list,
oops, I meant white-list of course ....
That's what I figured. :)
so, I don;t
think this is possible But still, a super-user can of course give the permission to add new events to all Roles in the system and you will have the same result. Does that make sense ?
That does make sense. We'll likely just try to use the API to log events when starting a task and if we receive an error we can bubble that up to the user letting them know that they need to either get the right permission or accept that they won't get messages in the oVirt log while the task completes.
Eli - not that the design includes checking for permissions on objects, why wouldn't we add this permission (ActionGroup) to other admin roles as well?
You mean in DB upgrade , right ?
well, in design, but then yes, as part of upgrade to fix the relevant pre-defined roles
this is only for admin roles, not user roles. what's the risk in allowing admins to inject external events?
IIUC , you are right , no risk
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Eli Mesika" <emesika@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Christopher Morrissey" <Christopher.Morrissey@netapp.com> Sent: Friday, November 23, 2012 8:38:34 AM Subject: Re: [Engine-devel] Design review summary for 3.2 - adding support for External Events
On 11/23/2012 01:10 AM, Eli Mesika wrote:
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Christopher Morrissey" <Christopher.Morrissey@netapp.com> Cc: "Eli Mesika" <emesika@redhat.com>, "engine-devel" <engine-devel@ovirt.org> Sent: Thursday, November 22, 2012 8:35:56 AM Subject: Re: [Engine-devel] Design review summary for 3.2 - adding support for External Events
On 11/20/2012 04:07 PM, Morrissey, Christopher wrote: ...
> Hi Eli, > > I've perused the design and it looks very good for the purpose > of > adding events to the log as back end tasks on the NetApp VSC > are > started and complete. > > I do have one question. As part of the new UI plugin framework > that > Vojtech is working on he added the capability to retrieve a > session > ID that will be used outside of the oVirt engine to invoke > REST > API > calls. I'm assuming this session would have the same role as > the > user that is currently logged in. > > According to the event log design, only the Super user will > have > permissions to add events by default. This would mean that if > anyone > other than the super user is logged in and performing any > tasks > through the NetApp plugin, the server side of the VSC will > likely > not be able to log events. This could be confusing for users > as > sometimes they see events showing up giving them information > on > the > task progress and sometimes they don't depending on the role > logged > in. > > Would it make sense to allow all roles to log events by > default? > I'm > not sure what security problems would arise given that it is > just a > log and they would be tagged as external events.
Hi Christopher, our security model implies a black-list,
oops, I meant white-list of course ....
That's what I figured. :)
so, I don;t
think this is possible But still, a super-user can of course give the permission to add new events to all Roles in the system and you will have the same result. Does that make sense ?
That does make sense. We'll likely just try to use the API to log events when starting a task and if we receive an error we can bubble that up to the user letting them know that they need to either get the right permission or accept that they won't get messages in the oVirt log while the task completes.
Eli - not that the design includes checking for permissions on objects, why wouldn't we add this permission (ActionGroup) to other admin roles as well?
You mean in DB upgrade , right ?
well, in design, but then yes, as part of upgrade to fix the relevant pre-defined roles
Added to the install/upgrade section of feature detailed design http://wiki.ovirt.org/wiki/Features/Design/DetailedExternalEvents#Installati...
this is only for admin roles, not user roles. what's the risk in allowing admins to inject external events?
IIUC , you are right , no risk
Hi please note that this section http://wiki.ovirt.org/wiki/Features/Design/DetailedExternalEvents#Permission... was changed and approved by PM (Miki)
On 11/29/2012 11:11 PM, Eli Mesika wrote:
Hi
please note that this section http://wiki.ovirt.org/wiki/Features/Design/DetailedExternalEvents#Permission... was changed and approved by PM (Miki)
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Invoke ..api/events/add API giving at least AuditLogType, Severity, Origin & CustomEventId
why do you need the AuditLogType - you already know it is ExternalEvent/Alert? you only need to know the severity iiuc.
When the Event/Alert is on a specific object, the object instance id should be set.
what if it is on multiple objects, like events are today? ...
Permissions on Entity Instances
There will be no permission check on entity instances on which External Events are injected
this means this permission is always at system level, breaking the current permission scheme where permission can be given on a portion of the system.
The reason is that in order to invoke an External Events on an entity instance, the invoker should know the entity instance UUID and therefore we had already checked that the invoker has the right permissions on the entity instance when he gets the information.
UUID are not cryptographically secure. knowing a UUID is not a way to decide to give a permission. (also, this is an admin action, and admins always see all objects in the system today)
Also, double checking that in the AddExternalEvent command is not simple, since each Entity may have several ActionGroups (Create, Edit etc.) associated with it, so it is not clear which to check
it is very clear - you check for each entity the user has the new ActionGroup that allows to inject events (same one you added to the superuser and to the newly created special role).
So, in order to keep things simple, we will assume that if the caller to Add External Event has the Entity UUID in hand, all we have to check is that he has permission to inject External Events
as i stated above, this means you are creating an ActionGroup which is global, regardless of the entity the role with it is given on. ...
User Experience
Global External Events will be displayed on the Global Events TAB Entity instance External Events will be displayed on the Events TAB when selecting the Entity instance
1. not clear here they will also be displayed in the global tab? 2. not clear here that multiple entities can be specified for an event. ...
Installation/Upgrade
Add additional fields to audit_log table upon upgrade Add the permission(ActionGroup) to manipulate External Events to other admin roles already defined upon upgrade.
but in permission it is stated only superuser and a new role will be given this actiongroup, and here more admin roles are mentioned (if so, which is the correct one). Thanks, Itamar
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Eli Mesika" <emesika@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Tuesday, December 4, 2012 2:09:56 AM Subject: Re: [Engine-devel] Design review summary for 3.2 - adding support for External Events
On 11/29/2012 11:11 PM, Eli Mesika wrote:
Hi
please note that this section http://wiki.ovirt.org/wiki/Features/Design/DetailedExternalEvents#Permission... was changed and approved by PM (Miki)
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Invoke ..api/events/add API giving at least AuditLogType, Severity, Origin & CustomEventId
why do you need the AuditLogType - you already know it is ExternalEvent/Alert? you only need to know the severity iiuc.
Sorry for the late respond (too many urgent issue :-)) I need that because we have not just and Alert but also Warning , Error & Normal External Events
When the Event/Alert is on a specific object, the object instance id should be set.
what if it is on multiple objects, like events are today?
The statement says 'at least' so one/multiple entity IDs should be applied as well
...
Permissions on Entity Instances
There will be no permission check on entity instances on which External Events are injected
this means this permission is always at system level, breaking the current permission scheme where permission can be given on a portion of the system.
I had talk with that with miki and that was our understanding of the requirement, it can be changed if it does not match the requirements or if we have misunderstood them.
The reason is that in order to invoke an External Events on an entity instance, the invoker should know the entity instance UUID and therefore we had already checked that the invoker has the right permissions on the entity instance when he gets the information.
UUID are not cryptographically secure. knowing a UUID is not a way to decide to give a permission. (also, this is an admin action, and admins always see all objects in the system today)
Also, double checking that in the AddExternalEvent command is not simple, since each Entity may have several ActionGroups (Create, Edit etc.) associated with it, so it is not clear which to check
it is very clear - you check for each entity the user has the new ActionGroup that allows to inject events (same one you added to the superuser and to the newly created special role).
Yea, as I said above , we didn't look in External Events as an permission per object type and that leads to a general implementation.....
So, in order to keep things simple, we will assume that if the caller to Add External Event has the Entity UUID in hand, all we have to check is that he has permission to inject External Events
as i stated above, this means you are creating an ActionGroup which is global, regardless of the entity the role with it is given on.
This can be changed if required and still be ready until the 24 DEC deadline
...
User Experience
Global External Events will be displayed on the Global Events TAB Entity instance External Events will be displayed on the Events TAB when selecting the Entity instance
1. not clear here they will also be displayed in the global tab? 2. not clear here that multiple entities can be specified for an event.
...
Installation/Upgrade
Add additional fields to audit_log table upon upgrade Add the permission(ActionGroup) to manipulate External Events to other admin roles already defined upon upgrade.
but in permission it is stated only superuser and a new role will be given this actiongroup, and here more admin roles are mentioned (if so, which is the correct one).
Thanks, Itamar
On 12/16/2012 01:01 AM, Eli Mesika wrote:
Invoke ..api/events/add API giving at least AuditLogType, Severity,
Origin & CustomEventId
why do you need the AuditLogType - you already know it is ExternalEvent/Alert? you only need to know the severity iiuc. Sorry for the late respond (too many urgent issue :-))
I need that because we have not just and Alert but also Warning , Error & Normal External Events
yes, but the fact they are external events is known already in this API, so why do you need more than the severity in the API?
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Eli Mesika" <emesika@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Miki Kenneth" <mkenneth@redhat.com>, "Barak Azulay" <bazulay@redhat.com>, "Yair Zaslavsky" <yzaslavs@redhat.com> Sent: Sunday, December 16, 2012 8:21:16 AM Subject: Re: [Engine-devel] Design review summary for 3.2 - adding support for External Events
On 12/16/2012 01:01 AM, Eli Mesika wrote:
Invoke ..api/events/add API giving at least AuditLogType, Severity,
Origin & CustomEventId
why do you need the AuditLogType - you already know it is ExternalEvent/Alert? you only need to know the severity iiuc. Sorry for the late respond (too many urgent issue :-))
I need that because we have not just and Alert but also Warning , Error & Normal External Events
yes, but the fact they are external events is known already in this API, so why do you need more than the severity in the API?
You are right, updated the wiki and added also API sample for adding event code http://www.ovirt.org/Features/Design/DetailedExternalEvents#API
Eli, I've reviewed the Detailed Design for External Events. Overall, the design looks good, but I have a few questions: 1. Can I provide additional data with the event: AuditLogSeverity = EXTERNAL_EVENT_WARNING Message = "Enclosure RACK15ENC3: Fan in bay 5 failed" Vendor = "HP" CustomEventId = 12345 DataCenterId = "Houston" (I assume this is really the UUID of the data center) ExtraData = { "enclosure": "RACK15ENC3", "bay": 5, "partnum": "412140-B21", "spare": "413996-001", "model": "Active Cool 200 Fan", "zone": 2} 2. What is the meaning of this statement on the DetailedDesign page: External Events can not use application variables, therefore no '$' expressions should appear in the Event/Alert free message text Does this mean the Message has to be fixed text with no substitution variables? Can I do this: Message = "Enclosure {ExtraData.enclosure}: Fan in bay {ExtraData.bay} failed. Replace with {ExtraData.spare}." 3. Considering that the Event has a number of IDs associated with it (UserId, DataCenterId, HostId, VmId, etc), does that mean an event can be associated with multiple entities at once? "Host X in Cluster Y in Datacenter Z has exceeded the critical temperature threshold. Shutting down." How will this be expanded in the future as oVirt Engine becomes aware of more types of entities (enclosures, rack managers, advanced networking switches/fabrics)? Is it be possible for an event to be associated with multiple hosts? To return to the fan failure scenario above, if a fan in an enclosure fails, all of the hosts in that fan's fanzone will be effected. Thanks, --Chris
----- Original Message -----
From: "Chris Frantz" <Chris.Frantz@hp.com> To: "Eli Mesika" <emesika@redhat.com>, "engine-devel" <engine-devel@ovirt.org> Sent: Monday, November 19, 2012 6:03:37 PM Subject: RE: [Engine-devel] Design review summary for 3.2 - adding support for External Events
Eli,
I've reviewed the Detailed Design for External Events. Overall, the design looks good, but I have a few questions:
Hi Chris Please see my answers below
1. Can I provide additional data with the event:
AuditLogSeverity = EXTERNAL_EVENT_WARNING Message = "Enclosure RACK15ENC3: Fan in bay 5 failed" Vendor = "HP" CustomEventId = 12345 DataCenterId = "Houston" (I assume this is really the UUID of the data center) ExtraData = { "enclosure": "RACK15ENC3", "bay": 5, "partnum": "412140-B21", "spare": "413996-001", "model": "Active Cool 200 Fan", "zone": 2}
I have added a CustomData field to the design to support that.(please see updated design page)
2. What is the meaning of this statement on the DetailedDesign page:
External Events can not use application variables, therefore no '$' expressions should appear in the Event/Alert free message text
Does this mean the Message has to be fixed text with no substitution variables? Can I do this:
Message = "Enclosure {ExtraData.enclosure}: Fan in bay {ExtraData.bay} failed. Replace with {ExtraData.spare}."
We are using ${variable name} in messages to automatically substitute values to variables that appears in the message text. In order to prevent confusion between application variable substitution and external events variable substitution we offer that external events will use a different pattern, the sample you have attached above will perfectly work. This is just a suggestion, not an enforcement, since the Audit Log mechanism will leave variables in the text that failed variable substitution as is, so if the text has a ${myvar} inside the text, it will not be touched. In any case, it is the plug-in responsibility to build and parse those variables while the engine will store the whole message as plain text.
3. Considering that the Event has a number of IDs associated with it (UserId, DataCenterId, HostId, VmId, etc), does that mean an event can be associated with multiple entities at once? "Host X in Cluster Y in Datacenter Z has exceeded the critical temperature threshold. Shutting down."
Sure, you just have to set all relevant IDs when you add the event.
How will this be expanded in the future as oVirt Engine becomes aware of more types of entities (enclosures, rack managers, advanced networking switches/fabrics)?
When new entities will be added to the system, we will expand the Audit Log mechanism to support those events. A good example of that is Gluster, that once added , has gluster_volume_id and gluster_volume_name in audit_log table and its own events.
Is it be possible for an event to be associated with multiple hosts?
Currently not, but you can still invoke the same event on multiple entities
To return to the fan failure scenario above, if a fan in an enclosure fails, all of the hosts in that fan's fanzone will be effected.
I think that even for this scenario, you still look at it as a Host event, you probably expect that when you are selecting the Host in the UI, you will see this event, so, even if the event was on a collection of Hosts , its still technically a loop that adds the same event for the hosts in that fan's fanzone. Does that make sense ?
Thanks, --Chris
participants (5)
-
Eli Mesika -
Frantz, Chris -
Itamar Heim -
Morrissey, Christopher -
Vojtech Szocs