6.1 The Constraints Table Panel

The left side of the Health Debugger page is referred to as the Constraints Table view.

Figure 6-2 The Constraints Table View

The appearance of this view can change, depending on the Constraint Type you select in the Constraint drop down list. In effect, if you change from the health selection, you will be debugging other constraints. For a description of these constraint types, see Section 4.1.2, The Constraint Type List. Different objects selected for the view change the Match Context in which the constraint is executed, which is useful for comparing how the constraint evaluates other objects.

The Constraints Table View is composed of several parts:

6.1.1 The Match Context Area

The Health Debugger provides the general identification of a Grid object in the Match Context area of the Constraints Table View. The Match Context defines every object that is available to the constraint you are viewing.

In this example, the identifying Facts in the Match Context include:

  • Matrix: The icon and a text string identifies the machine that matches the grid name given to the Orchestrate Server where this object exists.

  • Object icon: The object icon and a text string identifies the object (VM host, Repository, or that matches the user who is running the job. If the object icon has a red cross overlaid, it is unhealthy.

  • Object list: The object drop down list shows all named objects of the type selected in the Explorer Tree. The objects in the list that are currently offline display with a dimmed icon. If available, a listed object has a colored dot by its side. The color of the dot (blue or gray ) and the object type it accompanies has significance:

    • A blue dot with the All <Object Type> label indicates that at least one object in the list matches the constraints and is healthy.

    • A gray dot with the All <Object Type> label indicates that no objects of this type match the constraints.

    • A blue dot with a named, selected object indicates that its constraints match and it is healthy.

    • A gray dot by a named, selected object indicates that its constraints do not match and that it is not healthy.

6.1.2 The Verbose Check Box

When you select the Verbose check box, the reason string specified in the policy is displayed in the Constraints tree. For more information, see Section 4.1.5, The Constraints Column of the Constraints Table View.

6.1.3 The Capable Objects Summary

Directly under the Object list in the constraint view, a populated string summarizes the resources that are capable of servicing the job. For example, 11 healthy Resources of 12 online indicates that 11 of the 12 total online Resources are healthy.

6.1.4 The Constraints Column of the Constraints Table View

The Constraints column of the constraints table view shows the logical hierarchy (that is, a “tree” format) of the constraints that are defined by the Policies associated with the Job. You can identify the status of the listed constraints by the icons that might be displayed in the far left column of the table:

  • no icon: The constraint passes the match. It is a “true” match. No red icons are displayed next to any listed constraint.

  • red dot icon: The constraint does not pass the match. The figure below shows that the resource vmh5slesx cannot run the job because its health constraints do not match.

  • red octagonal icon: For convenience, just one of the constraints is identified as the blocking constraint. This is the constraint that the system has determined as responsible for the constraint as a whole to fail (note that individual constraint lines can fail without causing the the entire constraint to fail).

  • green dot icon: A failing constraint has been disabled so that it behaves like a match (pass). The figure below shows the green dot icon next to that the constraint that was formerly failing and can now be forced to behave as a match.

If you right-click a constraint in the table, a popup menu with three options is displayed. This menu lets you change the status of the constraint. Disabling a constraint is useful if you want to temporarily relax a condition without editing or redeploying the whole policy and potentially affecting other objects that share the policy. A disabled constraint can be re-enabled later.

  • Show Admin View: Select this option to open the Admin View for the specific object selected.

  • Disable Constraint: Select this option to disable (attach a green dot icon to) a constraint. Disabling a constraint with this function effectively makes it match, a condition that can prove useful if you want to perform a “what if” test without actually changing a policy.

  • Enable All Constraints: Select this option if you have disabled one or more constraints during testing and you want to restore them to the enabled state.

NOTE:Health constraints are always re-evaluated in the debugger. The last system execution (cached constraint) is not available for health constraints.

The Policy column of the constraints table displays the policy name that contributed the constraint. Right-click a policy name to open a popup menu offering the option to open the policy editor for the specified policy. The menu also includes constraint enabling or disabling options, just as the popup menu for constraint column does.

Figure 6-3 The Popup Menu Launched from the Policy Column