The PlateSpin Orchestrate Event System integrates with the Job Scheduler. Event notifications can start jobs and can also invoke Event handler methods in long-running jobs. In turn, a job can react to the Event by starting other PlateSpin Orchestrate actions, by modifying object attributes, or by executing another external process.
For example, an Event notification can occur when a VM Host has exceeded its configured load limits. This Event can start a job that migrates VMs off of the loaded VM Host or VM Hosts.
PlateSpin Orchestrate supports two Event types:
Built-in Events, such as change of status of the health of a resource's or a change in the online status of the resource.
Rule-based Events that are triggered when the attributes of an object satisfy the rules (constraint conditions) defining the Event.
This section includes the following information:
An Event notifies two other PlateSpin Orchestrate services– the Job Scheduler and the Job Broker. The Job Scheduler starts jobs that are awaiting an Event to trigger them.
The Job Broker invokes a callback on any long-running job that has registered for notification of an Event.
See The PlateSpin Orchestrate Job Scheduler
in the PlateSpin Orchestrate 2.0 Development Client Reference for more information about setting up a Job Schedule. Also see Job Architecture
in the PlateSpin Orchestrate 2.0 Developer Guide and Reference for more information about how jobs can register for event notification.
Built-in events occur when a managed object comes online/offline or has a health status change.
PlateSpin Orchestrate uses the following built-in Events to keep managed objects synchronized.
Table C-1 PlateSpin Orchestrate Built-in Events
For example, when a resource comes online (that is, the agent connects to server), the RESOURCE_ONLINE Event is fired and both Scheduled Jobs with a trigger for that Event and long-running jobs with Event handlers are notified.
The RESOURCE_ONLINE built-in Event is used by the embedded discovery jobs, such as for discovering operating system and CPU information (osInfo and cpuInfo jobs). Both osInfo and cpuInfo job archives (.job) include a schedule file (.sched) specifying a trigger (.trig) that allows these jobs be started when notification of the RESOURCE_ONLINE Event occurs.
Rule-based Events are defined in an XML document and deployed to the PlateSpin Orchestrate Server and managed using the PlateSpin Orchestrate Development Client. Rules can be a simple object attribute (fact) equivalency check or they can use AND,OR, IF, ELSE logic, among other things, in an Event ruleset.
The rules follow the same syntax as the constraints that are defined in XML policy files for all Grid Objects, such as Jobs, VM Hosts, etc.
The PlateSpin Orchestrate Event Service evaluates the rules; if the rules pass, an Event notification occurs.
The XML Schema document specification can be found in <install dir>/doc/xsds/event_1_0_0.xsd.
The Event XML specification is composed of three sections.
<context>
<trigger>
<reset>
NOTE:Both the <context> and <trigger> sections are required.
The context section defines the context in which the Event rules are evaluated. With Events, you specify what objects are in the Event rule context in this section. The available objects are Job, Jobinstance, Resource, Repository, User, and VMHost. From these objects, you can specify one object set to iterate over and optionally a single instance of the object.
The trigger section defines the rules for when an Event notification occurs. The <trigger> format is the same syntax as <constraints> used in policies.
The optional <reset> section defines the rules for when an Event is reset. If the <reset> rule is not used, an Event is reset based on a timeout. The <reset> format is also the same syntax as in <constraints> used in policies.
The resetInterval attribute is set on the <event> XML element. If "resetInterval" and <reset> is not used, the default timeout for resetting is 10 minutes.
The following example (taken from the "vmhost.event" in <install dir>/examples/events) defines that a notification occurs when a VM Host becomes overloaded.
1<event> 2 3 <context> 4 <vmhost /> 5 </context> 6 7 <trigger> 8 <gt fact="vmhost.vm.count" value="0" /> 9 <gt fact="vmhost.resource.loadaverage" value="2" /> 10 </trigger> 11 12 <reset> 13 <lt fact="vmhost.resource.loadaverage" value=".5" /> 14 </reset> 15 16</event>
Lines 3-5: Defines the context for the Event’s rule evaluation.
Line 4: The context specifies for all VM Host objects, so the Event Service iterates over all VM Hosts. On each VM Host, the <trigger> rule will be evaluated, so in this case, the Event context is composed of one or more VM Hosts.
Lines 7-12: Defines the Trigger rule to determine if this Event is to fire notifications or not. If the trigger rule does not pass, then no Event notifications occur.
Line 8: Consider only VM Hosts that have at least one VM instance running.
Line 9: Check the running average of the VM Host’s load average if it exceeds a threshold value. In this case if the average is greater than 2.
Lines 12-14: Defines the Reset rule to determine if a previously triggered VM Host can be reset and triggered again.
Line 13: Only reset if the running average of the VM Host’s load average drops below a threshold.
So when a VM Host passes the trigger rule, the VM Host does not pass the trigger rule again until the reset rule (load average drops below threshold) passes.
See the repository.event example (<install dir>/examples/events/repository.event) for an Event with a rule that evaluates the freespace fact on all repository objects.