Deployment Jobs

Administration > Monitoring > Deployment Jobs

Alternatively, click Deployment Jobs.

The OMi deployment data flow includes the following phases:

1. The assignment phase that defines which CI will be monitored against the values defined for the corresponding CI type referenced in a management template or aspect.

2. The creation of the deployment jobs phase that places the requests resulting from assignments into a queue to be processed.

3. The deployment phase that executes the corresponding deployment jobs (by transferring data to the managed nodes).

OMi supports the following deployment strategies:

• Assignment with the immediate deployment (this is the default mode; all steps from the above list are executed one after the other).

• The maintenance window-based deployment (the first two steps are executed together but the deployment phase takes place at a user-defined time). This strategy is recommended when you must automate the execution of deployment jobs during maintenance time periods.

  To enable the maintenance window-based deployment, set the Create suspended deployment jobs setting to true in Infrastructure Settings for Monitoring Automation (in the Infrastructure Settings page, select Applications and use the list to set the administration context to Monitoring Automation). This will create suspended deployment jobs, which are placed in the job queue. You can deploy them at a later time using the opr-jobs command-line interface. (To manually start a single deployment job in the SUSPENDED state, you can also select the job in the Deployment Jobs page and click Restart deployment jobs . However, for automation purposes, use the opr-jobs command-line interface.)
  

  For more information, see opr-jobs Command-Line Interface.

  Note The Create suspended deployment jobs infrastructure setting does not affect deployment jobs created when synchronizing installed packages or policy templates.
  If the infrastructure setting is changed back to false (default), all subsequent deployment jobs are created in the PENDING state, which means they will be executed as soon as possible.

  Tip You can view the job queue in the Deployment Jobs page or by running the opr-jobs -list command.

Delta deployment provides the ability to transfer only non-deployed portions of data by determining the differences between already deployed configuration (management templates, aspects and policy templates) and the configuration that was assigned but not yet deployed to the monitored nodes due to various reasons.

Below are some examples:

• An assignment with the immediate deployment was created but the deployment job did not complete because the HPE Operations Agent was unreachable. After the Agent is restarted, only the delta deployment takes place, meaning that only the data that was not yet deployed is transferred to the monitored nodes (and already deployed data is skipped).

• A new instrumentation category package of an existing instrumentation category was uploaded to the Monitoring Automation database. Though it will not initiate the automatic redeployment, it sets the flags, and the next deployment job will deploy the changes.

You specify if you want to redeploy the full configuration (policy templates and instrumentation) or deploy only the configuration that was not yet transferred to the monitored nodes using one of following methods:

• The -force option of the opr-agt command-line interface (selecting this option redeploys the full configuration). If this option is not set, only the configuration that was already assigned but not yet delivered to the HPE Operations Agent is deployed. For more information, see opr-agt Command-Line Interface.

• The options Re-Deploy Monitoring Configuration and Deploy not yet Deployed Monitoring Configuration available in the Administration > Setup and Maintenance > Monitored Nodes page. For more information, see Monitored Nodes.

In addition, OMi automatically checks all assignments every 12 hours and identifies the changes that may require redeployment of an assignment. (Normally, the RTSM issues a notification about the changes, but if their number is too high, you only receive a mass update notification.)

Use the Deployment Jobs page to manage deployment jobs. Some examples of tasks are:

• Investigate and repair jobs in the FAILED state. Deployment jobs may fail when OMi cannot communicate with the node, for example because of network or certificate problems.

• Investigate and repair jobs remaining in the PENDING state longer than expected. Pending jobs are jobs that are waiting to be executed on a node.

• Manually restart single jobs in the SUSPENDED state after repairs or other updates. Jobs may be manually suspended by an OMi administrator. Jobs may also have the status SUSPENDED if another job for the same node has failed.

  To automate deployment jobs suspended during maintenance time periods, use the opr-jobs command-line interface.

• Monitor running jobs. As soon as a deployment job is completed successfully, it is deleted from the job queue.

Select the job(s) you want to restart and click Restart deployment jobs . The state of the selected jobs changes to RUNNING (a job is being executed), PENDING (a job is awaiting execution), or FAILED (a job has failed).

When you restart a deployment job, the state of all other jobs for the same node changes to PENDING.

Select the job(s) you want to suspend and click Suspend deployment jobs . The state of the selected jobs changes to SUSPENDED.

Select the job(s) you want to delete and click Delete deployment jobs . The selected deployment jobs are removed from the list.

To restart jobs for deleted deployment jobs, click Start jobs for undeployed deployments .

Problem: After assigning configuration to a monitored node Monitoring Automation does not create deployment jobs. The Deployment Jobs screen does not show any deployment jobs.

Solution: Monitoring Automation creates a deployment whenever you create or remove an assignment from a policy template, aspect, or management template, or when you modify the assigned configuration. When the configuration changes, Monitoring Automation compares the changes with what is already deployed and then decides whether to create a deployment job or not.

You can check the following log file for information on Monitoring Automation's evaluation of required deployment jobs:

<OMi_HOME>/log/jboss/opr-configserver.log

Problem: A deployment job fails with the following error message:

Could not deploy the health check configuration to the node. Agent versions earlier than 11.12.0 are not supported. Upgrade the agent to version 11.12.0 or later and redeploy the configuration.

Solution: HPE Operations Agents version 11.12 and earlier do not support parameterized policy templates such as the Health Check - Heart Beat Policy template, which contains a parameter for the heartbeat interval. The scheduled task policy template can therefore not be deployed to agents earlier than 11.12. To check the health of any HPE Operations Agents connected to Monitoring Automation, upgrade the agents to version 11.12 or later. See also Configure health checks.

To communicate with a node (for example, to deploy configuration or for monitoring), OMi uses the node's primary DNS name. This name by default takes priority over any IP addresses entered for the node. The node's hostname must therefore be resolvable by DNS to avoid failed deployment jobs.

For more information, see DNS Names Versus IP Addresses.