Event stream namespace

The ${/#event_stream.event_namespace} part of the relationship translates to one of three event stream namespaces:

• EmsEvent if the event’s origin was an external management system (i.e., a provider). An EmsEvent instance contains all information about its virtual machine, host, and provider related to the event.

• MiqEvent if the event’s origin was an internal CloudForms/ManageIQ-initiated policy event.

• RequestEvent if the event is related to an automation request (e.g., request_created).

These can be seen in Figure 15-2.

Figure 15-2. Event stream namespaces

Event stream source

Within each of the event stream namespaces are classes that define the event stream source instances. The selection of source class is made from the substitution of the ${/#event_stream.source} part of the /System/Process/Event rel5 relationship. We can see that for the EmsEvent namespace, these represent the various external management systems (Amazon, OpenStack, etc.). See Figure 15-3.

Figure 15-3. Event stream sources

Event type

Under the appropriate event stream source classes are instances that define the processing required for each event type. The selection of event type is made from the substitution of the ${/#event_type} part of the /System/Process/Event rel5 relationship. We can see that these represent the various events that the EventCatcher::Runner workers detect from the provider message bus. Figure 15-4 shows the event types in the Amazon namespace.

Figure 15-4. Event types for the Amazon event stream source

The event type instances contain one or more relationships to event handlers in the /System/event_handlers namespace that define the actions to take for that event. For example, the Amazon event AWS_EC2_Instance_running will call the event_action_policy handler to push a new vm_start policy event through the Switchboard. It also calls the event_action_refresh handler to trigger a provider refresh so that the current instance details can be retrieved (see Figure 15-5).

Figure 15-5. The actions defined by the event type instance

Step 1

The first thing that we see in evm.log is the call to the EventHandler, along with arguments containing the RHEV API ids and hrefs describing the event source:

Args: [{:id=>"26790", 
    :href=>"/api/events/26790", 
    :cluster=>{
        :id=>"00000001-0001-0001-0001-000000000249", 
        :href=>"/api/clusters/00000001-0001-0001-0001-000000000249"}, 
    :data_center=>{
        :id=>"00000002-0002-0002-0002-000000000314",
        :href=>"/api/datacenters/00000002-0002-0002-0002-000000000314"}, 
    :host=>{
        :id=>"b959325b-c667-4e3a-a52e-fd936c225a1a", 
        :href=>"/api/hosts/b959325b-c667-4e3a-a52e-fd936c225a1a"}, 
    :user=>{
        :id=>"fdfc627c-d875-11e0-90f0-83df133b58cc", 
         :href=>"/api/users/fdfc627c-d875-11e0-90f0-83df133b58cc"}, 
    :vm=>{
        :id=>"4e7b66b7-080d-4593-b670-3d6259e47a0f", 
        :href=>"/api/vms/4e7b66b7-080d-4593-b670-3d6259e47a0f"}, 
    :description=>"VM rhel7srv010 started on Host rhelh03.bit63.net", 
    :severity=>"normal", 
    :code=>32, 
    :time=>2016-01-31 15:53:29 UTC, 
    :name=>"USER_RUN_VM"}]

Step 2

The EventHandler worker feeds the event into the Event Switchboard by creating and passing an EmsEvent EventStream object into Automate in the form of a queued request (we discuss queued requests more in Chapter 45). The EventHandlers translate the provider-specific arguments (API hrefs) into CloudForms object IDs and include these as arguments to the Automate request:

Args: [{:object_type=>"EmsEvent", 
        :object_id=>1000000007999, 
        :attrs=>{:event_id=>1000000007999, 
                 :event_stream_id=>1000000007999, 
                 :event_type=>"USER_RUN_VM", 
                 "VmOrTemplate::vm"=>1000000000023, 
                 :vm_id=>1000000000023, 
                 "Host::host"=>1000000000002, 
                 :host_id=>1000000000002}, 
                 :instance_name=>"Event", 
                 :user_id=>1000000000001, 
                 :miq_group_id=>1000000000002, 
                 :tenant_id=>1000000000001, 
                 :automate_message=>nil}]

Step 3

The request is dequeued and passed to the Automation Engine, which instantiates the /System/Process/Event entry point to the Event Switchboard, along with the arguments passed by the EventHandler:

<AutomationEngine> Instantiating [/System/Process/Event?
                   EventStream%3A%3Aevent_stream=1000000007999& 
                   Host%3A%3Ahost=1000000000002& 
                   MiqServer%3A%3Amiq_server=1000000000001& 
                   User%3A%3Auser=1000000000001& 
                   VmOrTemplate%3A%3Avm=1000000000023& 
                   event_id=1000000007999& 
                   event_stream_id=1000000007999& 
                   event_type=USER_RUN_VM& 
                   host_id=1000000000002& 
                   object_name=Event& 
                   vm_id=1000000000023& 
                   vmdb_object_type=event_stream]

Step 4

In the case of our RHEV USER_RUN_VM event, the Event Switchboard directs the processing to the /System/Event/EmsEvent/RHEVM/USER_RUN_VM instance, which contains relationships to two Automation event_handler instances (see Figure 15-7).

Figure 15-7. Relationships to event_handler instances

Step 5

The rel4 relationship of the /System/Event/EmsEvent/RHEVM/USER_RUN_VM instance calls /System/event_handlers/event_action_policy to initiate the creation of an internal generic vm_start event.

This completes the event processing workflow for the external USER_RUN_VM event.

Step 11

The process_evm_event internal method raises the vm_start (VM Power On) policy event and processes any actions (i.e., control policies) associated with the triggering of this policy event:

MIQ(MiqEvent#process_evm_event) Event Raised [vm_start]

In our case we have a VM control policy that runs an Invoke a Custom Automation action when the VM Power On event is triggered. The custom automation instance runs /Stuff/Methods/ObjectWalker (via /System/Request/Call_Instance). See Figure 15-8.

Figure 15-8. VM control policy that links a VM Power On event to Run ObjectWalker

Step 12

The automation request to run Call_Instance is queued for processing by the Automation Engine. This is subsequently dequeued and delivered to Automate:

MIQ(MiqAeEngine.deliver) Delivering 
                        {"namespace"=>"stuff", 
                        "class"=>"methods", 
                        "instance"=>"objectwalker", 
                        :request=>"call_instance", 
                        "MiqPolicy::miq_policy"=>1000000000001} 
        for object [VmOrTemplate.1000000000023] with state [] to Automate

We see object_walker running in the automation.log file.

Step 13

The internal process_evm_event method now raises the vm_start (VM Operation: VM Power On) alert and processes any actions associated with the triggering of this alert:

MIQ(MiqEvent#process_evm_event) Alert for Event [vm_start]

In our case we have an alert that sends a management event called test when the VM Operation: VM Power On alert is triggered (see Figure 15-9).

Figure 15-9. An alert to send a test management event

Step 14

The alert is queued for processing by the internal evaluate_alerts method, and our test event is run:

MIQ(MiqAlert.evaluate_alerts) [vm_start] Target: 
    ManageIQ::Providers::Redhat::InfraManager::Vm Name: [rhel7srv010], 
    Id: [1000000000023] Queuing evaluation of Alert: [VM Powered On]

This completes the full event processing workflow that started when the USER_RUN_VM event was detected from the RHEV provider. We saw the workflow pass through four stages: the handling of the external event, the raising and processing of the corresponding internal event, and the subsequent control policy and alert processing that may have been been associated with the event type.

Step 1.1

The variable substitutions are made from the EventStream object’s attributes, and we follow the relationship chain through the Switchboard:

Following Relationship [miqaedb:/System/Event/RequestEvent/Request/
                                                        request_created#create]

Step 1.2

The /System/Event/RequestEvent/Request/request_created instance contains a single rel5 relationship to /System/Policy/request_created. Once again we follow the relationship chain:

Following Relationship [miqaedb:/System/Policy/request_created#create]

Step 1.3

We are now in the /System/Policy namespace, which is where the event-specific policies are defined—that is, what to do when this type of event happens. Instances in this namespace typically have several entries (see Figure 15-10).

Figure 15-10. The schema of the /System/Policy/request_created instance

A request_created event is raised for all types of request, so before any event-specific policy can be implemented, the type of request must be determined.

Step 1.4

The /System/Policy/request_created instance first runs the get_request_type method to find out what type of request has been created:

Invoking [inline] method [/ManageIQ/System/Policy/get_request_type] 
                                                                with inputs [{}]
<AEMethod [/ManageIQ/System/Policy/get_request_type]> Starting
<AEMethod get_request_type> Request Type:<AutomationRequest>
<AEMethod [/ManageIQ/System/Policy/get_request_type]> Ending

The get_request_type method returns Request Type:<AutomationRequest>.

Step 1.5

The next entry in the /System/Policy/request_created schema is the rel4 relationship to /System/Process/parse_provider_category, so we continue to follow the relationship chain:

Following Relationship [miqaedb:/System/Process/parse_provider_category#create]

Some event processing can be provider-specific; for example, we may wish to handle the same event in a different way, depending on whether it came from VMware or OpenStack. The rel4 relationship from /System/Policy/request_created takes us to the parse_provider_category instance to determine the provider.

The parse_provider_category instance runs the parse_provider_category method:

Invoking [inline] method [/ManageIQ/System/Process/parse_provider_category] 
                                                                with inputs [{}]
<AEMethod [/ManageIQ/System/Process/parse_provider_category]> Starting
<AEMethod parse_provider_category> Parse Provider Category Key: nil  
                                                                Value: unknown
<AEMethod [/ManageIQ/System/Process/parse_provider_category]> Ending

The parse_provider_category method returns a value of unknown, as this automation request does not involve any provider operations (as it would if we were provisioning a VM, for example).

Step 1.6

The final entry in the /System/Policy/request_created schema is the rel5 relationship to /System/Policy/AutomationRequest_created (AutomationRequest having been substituted for ${#request_type}).

This doesn’t exist, so we see this warning message:

Instance [/ManageIQ/System/Policy/AutomationRequest_created] not found in 
                                            MiqAeDatastore - trying [.missing]

We can create a /System/Policy/AutomationRequest_created instance if we choose, but in this case the .missing instance does nothing, so we end that event-initiated chain.

Step 2.1

Following Relationship [miqaedb:/System/Event/RequestEvent/Request/ 
                                                         request_approved#create]

Step 2.2

Following Relationship [miqaedb:/System/Policy/request_approved#create]

Step 2.3

Following Relationship [miqaedb:/System/Process/ 
                                                  parse_provider_category#create]
Invoking [inline] method [/ManageIQ/System/Process/ 
                                        parse_provider_category] with inputs [{}]
<AEMethod [/ManageIQ/System/Process/parse_provider_category]> Starting
<AEMethod parse_provider_category> Parse Provider Category Key: nil  
                                                                   Value: unknown
<AEMethod [/ManageIQ/System/Process/parse_provider_category]> Ending

Step 2.4

Following Relationship [miqaedb:/System/Policy/ 
                                               AutomationRequest_Approved#create]
Instance [/ManageIQ/System/Policy/AutomationRequest_Approved] not found 
                                            in MiqAeDatastore - trying [.missing]

The request_approved event processing doesn’t call get_request_type, as there is no need for type-specific processing at this stage.

Once again we have no AutomationRequest_Approved method, so we terminate this event-initiated chain at this point.

Step 3.1

Following Relationship [miqaedb:/System/Event/RequestEvent/Request/ 
                                                         request_starting#create]

Step 3.2

Following Relationship [miqaedb:/System/Policy/request_starting#create]
Invoking [inline] method [/ManageIQ/System/Policy/get_request_type] 
                                                                 with inputs [{}]
<AEMethod [/ManageIQ/System/Policy/get_request_type]> Starting
<AEMethod get_request_type> Request Type:<AutomationRequest>
<AEMethod [/ManageIQ/System/Policy/get_request_type]> Ending

Step 3.3

Following Relationship [miqaedb:/System/Process/ 
                                                  parse_provider_category#create]
Invoking [inline] method [/ManageIQ/System/Process/ 
                                        parse_provider_category] with inputs [{}]
<AEMethod [/ManageIQ/System/Process/parse_provider_category]> Starting
<AEMethod parse_provider_category> Parse Provider Category Key: nil  
                                                                   Value: unknown
<AEMethod [/ManageIQ/System/Process/parse_provider_category]> Ending

Step 3.4

Following Relationship [miqaedb:/System/Policy/ 
                                               AutomationRequest_starting#create]
Instance [/ManageIQ/System/Policy/AutomationRequest_starting] 
                                  not found in MiqAeDatastore - trying [.missing]

Step 3.5

MIQ(AutomationRequest#call_automate_event_sync) 
                                      Raised event [request_starting] to Automate

At the end of this chain we see the automation request queuing the automation task:

Q-task_id([automation_request_1000000000031]) 
    MIQ(AutomationTask#deliver_to_automate) 
        Queuing Automation Request: [Automation Task]...
Q-task_id([automation_request_1000000000031]) 
    MIQ(AutomationTask#execute_queue) 
        Queuing Automation Request: [Automation Task]...