IBM Turbonomic

1. Generate a new keystore with certificate and key pair for the probe

   keytool -genkey -keyalg RSA -alias probe -keystore probe-keystore.jks -storepass -keysize 2048

2. Generate a certificate signing request (CSR)

   keytool -certreq -alias probe -keystore probe-keystore.jks -file probe.csr

PropsFile : '$OMNIHOME/probes/linux2x86/message_bus_turbonomic.props'
RulesFile : '$OMNIHOME/probes/linux2x86/message_bus_turbonomic.rules'
TransformerFile : '$OMNIHOME/probes/linux2x86/default/message_bus_turbonomic_parser.json'
TransportFile : '$OMNIHOME/java/conf/turbonomicWebhookTransport.properties'
TransportType : 'WebhookV2'
ConfigCryptoAlg :'AES_FIPS'
ConfigKeyFile :'/opt/IBM/tivoli/netcool/etc/security/keys/encryption.keyfile'
EnableSSL : 'true'
KeyStore : 'probe-keystore.jks'
KeyStorePassword : '<encrypted keystore password>'

webhookURI=/probe
serverBasicAuthenticationUsername=<username>
serverBasicAuthenticationPassword=<encrypted password>

$OMNIHOME/probes/nco_p_message_bus -propsfile $OMNIHOME/probes/linux2x86/message_bus_turbonomic.props

1. Set the following variables:

       PROBE_WEBHOOK_URL=https://<hostname>:<port>/probe
       TURBONOMIC_HOSTNAME=<api endpoint hostname>
       TURBONOMIC_ADMIN_USER=<turbonomic username>
       TURBONOMIC_ADMIN_PASSWORD=<turbonomic password>
       BASIC_AUTH_USERNAME=<probe basic authentication username>
       BASIC_AUTH_PASSWORD=<probe basic authentication password>

   Where:

   <hostname>:<port> is the probe hostname and port number

   <api endpoint hostname> is the Turbonomic API hostname

   <turbonomic username> is the Turbonomic username with permissions to create a workflow.

   <turbonomic password> is the Turbonomic user password

   <probe basic authentication username> and <probe basic authentication password> are the probe basic authentication credentials set in previous steps.

2. Get the JSESSIONID token:

       JSESSIONID=$(curl \
       --silent \
       --cookie-jar - \
       --insecure \
       https://${TURBONOMIC_HOSTNAME}/api/v3/login?hateoas=true \
       --data "username=${TURBONOMIC_ADMIN_USER}&password=${TURBONOMIC_ADMIN_PASSWORD}" \
       | awk '/JSESSIONID/{print $7}')

3. Create a workflow:

       curl \
       "https://${TURBONOMIC_HOSTNAME}/api/v3/workflows" \
       --insecure \
       --compressed \
       --header 'Accept: application/json' \
       --header 'Content-Type: application/json' \
       --header "cookie: JSESSIONID=${JSESSIONID}" \
       --request POST \
       -vv \
       --data @- <<EOF
       {
       "displayName": "Event Manager Probe",
       "className": "Workflow",
       "description": "Event Manager Webhook Probe",
       "discoveredBy": {
            "readonly": false
        },
       "type": "WEBHOOK",
       "typeSpecificDetails": {
         "url": "${PROBE_WEBHOOK_URL}",
         "method": "POST",
         "authenticationMethod": "BASIC",
         "username": "${BASIC_AUTH_USERNAME}",
         "password": "${BASIC_AUTH_PASSWORD}",
         "template": "\$converter.toJson(\$action)",
         "trustSelfSignedCertificates": true,
         "headers": [
            {
              "name": "Content-type",
              "value": "application/json"
            }
          ],
         "type": "WebhookApiDTO"
         }
       }
       EOF

4. Get the workflow UID for later use:

       WORKFLOW_UUID=$(curl \
       "https://${TURBONOMIC_HOSTNAME}/api/v3/workflows" \
       --insecure \
       --compressed \
       --header 'Accept: application/json' \
       --header 'Content-Type: application/json' \
       --header "cookie: JSESSIONID=${JSESSIONID}" \
       --request GET | jq -c ".[] | select(.typeSpecificDetails.url | contains(\"${PROBE_WEBHOOK_URL}\")) | .uuid" | tr -d '"')

1. Login to Turbonomic Console.

2. Navigate to the Settings Page and choose Policies.

3. Click New Automation Policy and select the policy type Virtual Machine. This sets the type of entity that your policy will affect. Refer to Working with Policies for more information.

   Specify the following details:

   • Provide a Name for the policy.

   • Add Scope: The scope determines which entities this policy will affect. Choose one or more groups, or create new groups and add them to the policy scope. These groups match the type of entity you have set for the policy.

   • Policy Schedule: The Select Schedule fly-out lists all the schedules that are currently defined for your instance of Turbonomic. Expand a schedule entry to see its details, you could skip it if you do not need a schedule.

   • Automation and Orchestration: You can define automation and orchestration settings for different action types within the same policy. Refer to an example setting below.

     Action Type: Displays a list of actions that are viable for the policy from which you can make your selections.

     Action Generation and Acceptance:

     • Do not Generate Actions Turbonomic: Never considers your selected actions in its calculations. For example, if you do not want to generate Resize actions for VMs in the policy, analysis will still drive toward the desired state, but will do so without considering resizing.

     • Generate Actions Turbonomic: Generates your selected actions to address or prevent problems. Choose from the following Action Acceptance modes to indicate how you would like the actions to execute:

       Recommend: Recommend the action so a user can execute it via the given hypervisor or by other means.

       Manual: Recommend the action and provide the option to execute that action through the Turbonomic user interface.

       Automatic: Execute the action automatically. For automated resize or move actions on the same entity, Turbonomic waits five minutes between each action to avoid failures associated with trying to execute all actions at once. Any action awaiting execution stays in queue.

   • Before Execution, Action Execution, and After Execution: By default, generated actions execute without the need for orchestration. Turbonomic gives you the ability to set up orchestration to affect the execution of actions. We have an example below applying Action Execution, which would send close event action through workflow:

     AFTER EXECUTION The default is Do Nothing. Other options include:

     Create Record in Orchestration: Turbonomic registers the action in the Orchestration log, showing that the given action has been executed. For example: A final ActionID could be created and with the final ActionState, the Type and Severity would be updated accordingly in Waiops. Those actions would also be updated to Waiops, and it would handle with the alerts with updated state: closed or cleared or keep open.

     Use Action Script: Run an action script that is set up for the POST entry point. The action script name must match the entity type and action type.

4. Save the policy.

5. Action events will be sent to the probe when an action is executed.

1. Get a list of Actions by market to test the workflow. Select an action from the list and copy the UUID which will be used to trigger an action event manually using API.

       curl \
       "https://${TURBONOMIC_HOSTNAME}/api/v3/markets/Market/actions?ascending=true" \
       --insecure \
       --compressed \
       --header 'Accept: application/json' \
       --header 'Content-Type: application/json' \
       --header "cookie: JSESSIONID=${JSESSIONID}" \
       --request GET

2. To test triggering an action event based on the UUID in the workflow, use one of the action UUID from the previous command in the actionId attribute value in the command below:

       curl --location --request POST "https://${TURBONOMIC_HOSTNAME}/api/v3/workflows/${WORKFLOW_UUID}" \
       --header 'Content-Type: application/json' \
       --header "Cookie: JSESSIONID=$JSESSIONID" \
       --insecure \
       --data-raw '{
           "operation": "TEST",
           "actionId": "637553640602793"
       }'

3. Verify that the probe received the test event either by checking the Alert Viewer UI or the probe debug logs.

• Turbonomic webhook flow can only be configured using the API.
• Turbonomic policy can be configured with one workflow per stage.
• Turbonomic sends events to one workflow if there are multiple similar policies which generated the action. If there is already a policy configured to notify another orchestrator, the probe may not be receiving an event.
• When a Turbonomic action is created, a event will be created. When the action is executed in Turbonomic, the webhook will also be notified and the event is cleared the NOI Alert Viewer. However an action can be closed in Turbonomic without being executed (e.g. an erroneous condition which is no longer occurring) in which case the probe will not receive any notification from Turbonomic. This in effect will leave the event open indefinitely in NOI Alert Viewer and it will need to be cleared manually.