NotificationCondition

A notification condition is related to an Event but differs in three distinct areas:

• Notification conditions are a persistent condition of the system or a component rather than a single occurrence.
  • They are ongoing rather than reoccurring, which is why they are generated from Notification Conditions.
  • They can be observed many times, but the condition is always the same.
  • A good test for this is if something 'is' wrong rather than something 'went' wrong.
• Notification conditions can be acted on to result in a resolved state, meaning the admin or user can and must take actions to 'fix' the condition or problem.
• Notification conditions contain state information based on admin or user input, meaning that they contain information about the condition (similar to events) but also contain the 'status' of the admin's view of the notification, whether it is currently open, dismissed, or ignored.

In general, questions can be asked to ascertain whether an Event or a Notification Condition is the right fit for an occurrence. These questions, along with some sample situations, are provided below.

• Is the occurrence the root cause of a potentially ongoing condition?
  • A VM migration failed because the VM's state was unknown. The root cause was that the state was unknown, not that the VM migration failed. Therefore, VM migration failed would be an event, while the unknown state would be a notification condition.
  • A VM service provision fails because there are no hypervisors that satisfy the requirements. This would be an event. Note that there may be a notification related to this failure, such as a service template requires a feature that does not exist on any hypervisors in the system, but this would be distinctly detected and managed from the provision failure event.
  • A request to MWS failed because the connection between MWM and MongoDB was misconfigured. The failed request can be represented as an event, but a notification condition should exist that the connection between MWM and MongoDB was down.
• Can an admin or user affect the outcome of the occurrence?
  • The outcome of a VM migration failing is in the past and cannot be changed by the admin. However, the outcome of a future VM migration can be changed when the admin resolves the root problem (i.e., VM state is unknown).

A notification condition is an observed condition for which notifications are created. These conditions are created or updated on every PUT request based on the NotificationCondition.escalationLevel, NotificationCondition.origin, NotificationCondition.message, NotificationCondition.objectType, and NotificationCondition.objectId fields. When notifications are requested, these observed conditions are used to create the notifications for the requesting user.

While notification conditions cannot be deleted, they 'expire' after a specified amount of time and are no longer considered as active conditions for which notifications are created.

Field Name	Type	PUT	Description
id	String	No	The identifier of the condition.
createdDate	Date	No	The date that the condition first started appearing.
details	Map<String, Map>	No	Arbitrary storage of details for this notification. This could include 'pluginType', 'pluginId', etc.
escalationLevel	EscalationLevel	No	The escalation level of the condition. This indicates who should care about the condition or who can respond to it. This CANNOT be EscalationLevel: INTERNAL.
expirationDate	Date	No	The date when the condition is considered 'expired' and notifications are no longer created for it. This is typically set using the expirationDuration field.
expirationDuration	Long	No	The duration in seconds that may pass before a notification will not be created for a user. Effectively, this can disable notifications from being created if they are too old. When this field is set, it will set the expirationDate field automatically each time the condition is updated or on creation. This field must be set to 1 or greater or else set to null.
message	String	No	A message detailing the notification and why it exists, with possible action items.
objectId	String	No	The identifier of the object that this notification affects, such as 'node1' or 'vm1'.
objectType	String	No	The object type that this notification affects, such as 'Node', 'VM', 'System', etc.
observedDate	Date	No	The latest date that the condition was observed. If this field is not set in an update request, it will automatically be set to the current date.
origin	String	No	The origin of the notification.

EscalationLevel

Value
USER
POWER_USER
ADMIN
INTERNAL