Every component discovered in a PlateSpin Orchestrate-enabled network is identified and abstracted as an object. Within the PlateSpin Orchestrate management framework, objects are stored within an addressable database called a Grid. Every Grid object has an associated set of facts and constraints that define its properties and characteristics. Essentially, by building, deploying, and running jobs on the PlateSpin Orchestrate Server, you can individually change the functionality of any and all system resources by managing an object’s facts and constraints.
The components that have facts include Jobs, Resources (including physical machines, virtual machines and VM hosts), Virtual Disks (vDisks), Virtual NICs (vNICs), Repositories, Virtual Bridges, and Users. The PlateSpin Orchestrate Server assigns default values to each of the component facts, although they can be changed at any time by the administrator (unless they are read-only).
The XML fact element defines a fact to be stored in the grid object’s fact namespace. The name, type and value of the fact are specified as attributes. For list or array fact types, the element tag defines list or array members. For dictionary fact types, the dict tag defines dictionary members.
See the examples in the directory, /allTypes.policy. This example policy has an XML representation for all the fact types.
Facts can also be created and modified in JDL and in the Java Client SDK
As a Job Developer, you might want certain constraints to be used for a job and you might specify these in the policy. These comprise a set of logical clauses and operators that are compared with the respective component’s fact values when the job is run by the Job Scheduling Manager. See
Remember, all properties appear in the job context, which is an environment where constraints are evaluated. These constraints provide a multilevel filter for a job in order to ensure the best quality of service the grid can provide.
This section includes the following information:
For further fact information found in jobs, see Section 7.0, Job Examples and Section 2.2.2, Using Facts in Job Scripts.
The following table explains the abbreviated codes used to describe facts for PlateSpin Orchestrate Grid objects:
Table 4-1 PlateSpin Orchestrate Fact Types
A fact junction is a special type of fact that provides a convenient way to access facts on Grid objects related to the one where the fact lookup is being performed. The following diagram shows the fact junction relationships of all the Grid objects:
Figure 4-1 Fact Junctions Between Objects in a Sample PlateSpin Orchestrate Grid
As an example of how a fact junction works, a fact lookup on vmhost.resource.id is redirected from the VM host object, through the junction onto the underlying physical Resource object. In other words, the value returned is the same as if a fact lookup for resource.id was performed on the underlying physical resource. This is accomplished with the following JDL:
vmhost1 = getMatrix().getGridObject(TYPE_VMHOST, "vmhost1") print vmhost1.getFact("vmhost.resource.id")
Another example is vdisk.repository.freespace, which returns the amount of free space in the repository that is associated with the virtual disk where the fact lookup is being performed:
vdisk = getMatrix().getGridObject(TYPE_VDISK, "vm1_vdisk1") print vdisk.getFact("vdisk.repository.freespace")
Note that the fact junction refers to the related Grid object rather than to any of its facts. Therefore, to obtain the ID of the repository associated with a given virtual disk, you must perform a lookup on vdisk.repository.id rather than vdisk.repository.
It is important to understand how the fact name is constructed from the junction, otherwise certain usages of fact junctions can be confusing, especially when used with facts that contain the dot (“.”) character. For example, starting with a vDisk Grid object as above:
vdisk = getMatrix().getGridObject(TYPE_VDISK, "vm1_vdisk1")
vDisk objects have a fact junction, vdisk.vm, that points to the VM associated with the vDisk. If you want to find all VNICs associated with this VM, remember that VMs have a fact resource.vm.vnics that provides the desired array. However, because PlateSpin Orchestrate accesses this fact by using the vdisk.vm fact junction, you must replace the resource component of the resource.vm.vnics fact with vdisk.vm. Therefore, the required code is:
print vdisk.getFact(“vdisk.vm.vm.vnics”)
Some fact junctions return an array of values rather than a single value. For example, the junction vmhost.repositories returns an array of all the repositories visible to the VM host where the lookup is being performed:
vmhost1 = getMatrix().getGridObject(TYPE_VMHOST, "vmhost1") print host1.getFact("vmhost.repositories")
In this case, you can also single out one of the Grid objects returned in the array and perform fact lookups on that object. For example, if the repository san1 is accessible by vmhost1, then
print vmhost1.getFact("vmhost.repositories[san1].freespace")
returns the amount of free space available in the san1 repository.
repo_host1 = getMatrix().getGridObject(TYPE_REPOSITORY, "host1") print repo_host1.getFact("repository.vmhosts[host1_demoAdapter].networks")
Fact junction lookups can be chained multiple times, even mixing use of single-valued and array-valued junctions:
vdisk = m.getGridObject(TYPE_VDISK, "vm1_vdisk1") print vdisk.getFact("vdisk.repository.vmhosts[vmhost1].networks") host1 = m.getGridObject(TYPE_RESOURCE, "host1") print host1.getFact("resource.vmhosts[host1_demoAdapter].repositories[san1].freespace")
For a more comprehensive list of available fact junctions, see the example factJunction.job stored at /opt/novell/zenworks/zos/server/examples on your server installation system.
This section includes the following information:
The Constraints/Facts tab opens a page that shows all of the effective constraints and facts for a Grid object. Each Grid object has an associated set of facts and constraints that define its properties. In essence, by changing the policy constraints and fact values for a job, you can change the behavior of the job and how the PlateSpin Orchestrate Server allocates available system resources to it. The Orchestrate Server assigns default values to each of the component facts, although they can be changed at any time by the administrator, unless they are read-only.
The following table lists the default facts created by the PlateSpin Orchestrate Server for the Job object.
NOTE:Facts with mode dynamic are dyamic read/write facts, which means you can dynamically change the values for that fact.
Facts with mode r/o have read-only values, which means they can be viewed but changes cannot be made.
Facts with mode del are deleteable, which means they can be deleted at any time. Where facts can be deleted in the Development Client, they can also be deleted in the GridObjectInfo.deleteFact() method in JDL.
Table 4-2 Job Facts
The following diagram illustrates the relationship between the Job Grid object facts and other Grid objects. It also shows the relationship between other discrete Grid object facts and the Job Grid object itself.
Figure 4-2 Job Fact Junctions
Table 4-3 Job Group Facts
A job instance is a currently running or recently completed job. All jobinstance facts are viewable only in the Policy Debugger page of the Jobs Monitor. You need to select the
check box to view these facts. These facts are not editable.NOTE:If the job you want to view finished previously, it is possible that it can no longer be viewed in the Policy Debugger if other jobs followed it on the Orchestrate Server.
Table 4-4 Jobinstance Facts
The following diagram illustrates the relationship between the Jobinstance facts and other Grid objects.
Figure 4-3 Jobinstance Fact Junctions
Joblet facts can be accessed only if you write code within the Joblet subclass of a JDL file. If you code a job to expose the joblet fact values, PlateSpin Orchestrate runs the scheduled joblets and you can see the joblet fact values in the Job Log tab of the Devlopment Client.
The available joblet facts and their descriptions are listed in the following table.
Table 4-5 Joblet Facts
This section includes the following information:
The Resource object (a physical or virtual machine) has an associated set of facts and constraints that define its properties. The PlateSpin Orchestrate Server assigns default values to each of the component facts, although they can be changed at any time by the administrator, unless they are read-only. Facts with mode r/o have read-only values, which can be viewed but changes cannot be made.
The following table lists the default facts created by the PlateSpin Orchestrate Server for the Resource object.
NOTE:Facts with mode dynamic are dyamic read/write facts, which means you can dynamically change the values for that fact.
Facts with mode r/o have read-only values, which means they can be viewed but changes cannot be made.
Facts with mode del are deleteable, which means they can be deleted at any time.
Table 4-6 Resource Facts
The following diagram illustrates the relationship between the Resource Grid object facts and other Grid objects. It also shows the relationship between other discrete Grid object facts and the Resource Grid object itself.
Figure 4-4 Resource Fact Junctions
The VM Host Resource object has an associated set of facts and constraints that define its properties. The PlateSpin Orchestrate Server assigns default values to each of the component facts, although they can be changed at any time by the administrator, unless they are read-only. Facts with mode r/o have read-only values, which can be viewed but changes cannot be made.
The following table lists the default facts created by the PlateSpin Orchestrate Server for the VM Host Grid object.
NOTE:Facts with mode dynamic are dyamic read/write facts, which means you can dynamically change the values for that fact.
Facts with mode r/o have read-only values, which means they can be viewed but changes cannot be made.
Facts with mode del are deleteable, which means they can be deleted at any time.
Table 4-7 VM Host Facts
The following diagram illustrates the relationship between the Vm Host Resource Grid object facts and other Grid objects. It also shows the relationship between other discrete Grid object facts and the VM Host Resource Grid object itself.
Figure 4-5 VM Host Fact Junctions
Table 4-8 Resource Group Facts
When you install the PlateSpin Orchestrate Agent on a machine, you can optionally install the Orchestrate Monitoring Agent along with it. The Monitoring Agent uses the Ganglia Monitoring Daemon (gmond) to automatically collect metrics and send them to the Orchestrate Monitoring Server. You can use the following command to check the status of an installed Monitoring Agent:
# /etc/init.d/novell-gmond status
If the daemon is operating normally, it returns a running status.
When you install and configure the Orchestrate Monitoring Agent (gmond), it is set by default to report metrics on port 8649, which is also detected by the Orchestrate Agent. When communication is established, the gmond daemon sends out metrics data, which are then gathered by the Orchestrate Agent and set as fact values associated with the resource where the daemon is running. You can verify the connection with the following command:
telnet localhost 8649
If gmond is running and communicating properly, an XML document listing the reported metrics is displayed.
This section includes information about the resource metrics facts that are gathered, the unit conversion performed by Orchestrate on the Ganglia-provided values, and how you can use these facts to help you manage the resources in the grid.
The Orchestrate Agent uses the metrics collected by gmond to create fact values for a given resource. These facts are therefore externally generated and are not among the default facts reported by the PlateSpin Orchestrate Agent. The agent updates these externally generated fact values every 30 seconds. All of these fact values have a resource.metrics. prefix.
For example, gmond collects a metrics value called load_one. The Orchestrate Agent sets this value as the resource.metrics.load_one fact.
To see a list of these facts in the Orchestrate Development Client,
In the Explorer panel, select a resource.
In the Workspace panel, select
.The names of the resource metrics facts are displayed in bold font (in the Development Client interface) because they were added as new facts to the default fact list. The following sample is a list of the default Ganglia-generated metrics facts with data type and an example value:
<fact name="resource.metrics.boottime" value="1239122234.0000" type="Real" /> <fact name="resource.metrics.bytes_in" value="208.8800" type="Real" /> <fact name="resource.metrics.bytes_out" value="68.9700" type="Real" /> <fact name="resource.metrics.cpu_aidle" value="76.9000" type="Real" /> <fact name="resource.metrics.cpu_idle" value="95.2000" type="Real" /> <fact name="resource.metrics.cpu_nice" value="0.0000" type="Real" /> <fact name="resource.metrics.cpu_num" value="2" type="Integer" /> <fact name="resource.metrics.cpu_speed" value="1596" type="Integer" /> <fact name="resource.metrics.cpu_system" value="0.3000" type="Real" /> <fact name="resource.metrics.cpu_user" value="4.0000" type="Real" /> <fact name="resource.metrics.cpu_wio" value="0.4000" type="Real" /> <fact name="resource.metrics.disk_free" value="27090" type="Integer" /> <fact name="resource.metrics.disk_total" value="48213" type="Integer" /> <fact name="resource.metrics.gexec" value="OFF" type="String" /> <fact name="resource.metrics.load_fifteen" value="0.2000" type="Real" /> <fact name="resource.metrics.load_five" value="0.4100" type="Real" /> <fact name="resource.metrics.load_one" value="1.1900" type="Real" /> <fact name="resource.metrics.machine_type" value="x86" type="String" /> <fact name="resource.metrics.mem_buffers" value="299" type="Integer" /> <fact name="resource.metrics.mem_cached" value="761" type="Integer" /> <fact name="resource.metrics.mem_free" value="65" type="Integer" /> <fact name="resource.metrics.mem_shared" value="0" type="Integer" /> <fact name="resource.metrics.mem_total" value="1989" type="Integer" /> <fact name="resource.metrics.os_name" value="Linux" type="String" /> <fact name="resource.metrics.os_release" value="2.6.27.19-5-pae" type="String" /> <fact name="resource.metrics.part_max_used" value="70.8000" type="Real" /> <fact name="resource.metrics.part_max_used.units" value="" type="String" /> <fact name="resource.metrics.pkts_in" value="0.4500" type="Real" /> <fact name="resource.metrics.pkts_out" value="0.6300" type="Real" /> <fact name="resource.metrics.proc_run" value="0" type="Integer" /> <fact name="resource.metrics.proc_total" value="411" type="Integer" /> <fact name="resource.metrics.swap_free" value="2039" type="Integer" /> <fact name="resource.metrics.swap_total" value="2047" type="Integer" /> <fact name="resource.metrics.vm_type" value="" type="String" /> <fact name="resource.metrics.vm_type.units" value="" type="String" />
These are the metrics reported in Orchestrate systems that use the gmond.conf created when Orchestrate Monitoring Agent was installed and configured. The open source gmond might include other metrics that can be monitored. You can modify the default Orchestrate gmond configuration file to report these metrics after it is initially installed and configured. For information about modifying the file, see the gmond.conf man page.
By using the XML constraint language, you can utilize these resource metrics facts as you would use any other fact in PlateSpin Orchestrate. For example, you could create an Event that sets thresholds for the amount of incoming network packets. When that threshold is exceeded, a Scheduled Job could be triggered or a notification e-mail sent. For more information, see Section 3.12, Using an Event Notification in a Job.
The Orchestrate Agent converts most of the Ganglia metrics values to PlateSpin Orchestrate standard units. This allows fact values to be compared in constraints without the need to perform conversions explicitly. In cases where units are not known or cannot be converted, a separate fact with a .units suffix is included. For example:
<fact name="resource.metrics.bytes_in" value="bytes/sec" type="String" />
The following table lists the resource.metrics facts and the units of measure used for each fact value:
Table 4-9 Resource Metrics Facts
This section includes the following information:
The vDisk object has an associated set of facts and constraints that define its properties. The PlateSpin Orchestrate Server assigns default values to each of the component facts, although they can be changed at any time by the administrator, unless they are read-only. Facts with mode r/o have read-only values, which can be viewed but changes cannot be made.
The following table lists the default facts created by the PlateSpin Orchestrate Server for the vDisk Grid object.
NOTE:Facts with mode dynamic are dyamic read/write facts, which means you can dynamically change the values for that fact.
Facts with mode r/o have read-only values, which means they can be viewed but changes cannot be made.
Facts with mode del are deletable, which means they can be deleted at any time.
Table 4-10 vDisk Facts
The following diagram illustrates the relationship between the Virtual Disk object facts and other Grid objects. It also shows the relationship between other discrete Grid object facts and the Virtual Disk Grid object itself.
Figure 4-6 Virtual Disk Fact Junctions
This section includes the following information:
The VNIC object has an associated set of facts and constraints that define its properties. The PlateSpin Orchestrate Server assigns default values to each of the component facts, although they can be changed at any time by the administrator, unless they are read-only.
The following table lists the default facts created by the PlateSpin Orchestrate Server for the VNIC Grid object.
NOTE:Facts with mode dynamic are dyamic read/write facts, which means you can dynamically change the values for that fact.
Facts with mode r/o have read-only values, which means they can be viewed but changes cannot be made.
Facts with mode del are deleteable, which means they can be deleted at any time.
Table 4-11 VNIC Facts
The following diagram illustrates the relationship between the VNIC object facts and other Grid objects. It also shows the relationship between other discrete object facts and the VNIC object itself.
Figure 4-7 Virtual NIC Fact Junctions
This section includes the following information:
The Repository object has an associated set of facts and constraints that define its properties. The PlateSpin Orchestrate Server assigns default values to each of the component facts, although they can be changed at any time by the administrator, unless they are read-only.
The following table lists the default facts created by the PlateSpin Orchestrate Server for the Repository Grid object.
NOTE:Facts with mode dynamic are dyamic read/write facts, which means you can dynamically change the values for that fact.
Facts with mode r/o have read-only values, which means they can be viewed but changes cannot be made.
Facts with mode del are deleteable, which means they can be deleted at any time.
Table 4-12 Repository Facts
The following diagram illustrates the relationship between the Repository object facts and other Grid objects. It also shows the relationship between other discrete Grid object facts and the Repository object itself.
Figure 4-8 Repository Fact Junctions
This section includes the following information:
The VNIC object has an associated set of facts and constraints that define its properties. The PlateSpin Orchestrate Server assigns default values to each of the component facts, although they can be changed at any time by the administrator, unless they are read-only.
The following table lists the default facts created by the PlateSpin Orchestrate Server for the Vbridge Grid object.
NOTE:Facts with mode dynamic are dyamic read/write facts, which means you can dynamically change the values for that fact.
Facts with mode r/o have read-only values, which means they can be viewed but changes cannot be made.
Facts with mode del are deleteable, which means they can be deleted at any time.
Table 4-14 Vbridge Facts
The following diagram illustrates the relationship between the Virtual Bridge (Vbridge) object facts and other Grid objects. It also shows the relationship between other discrete Grid object facts and the Vbridge object itself.
Figure 4-9 Virtual Bridge Fact Junctions
Table 4-15 Network Group Facts
This section includes the following information:
The User object has an associated set of facts and constraints that define its properties. The PlateSpin Orchestrate Server assigns default values to each of the component facts, although they can be changed at any time by the administrator, unless they are read-only.
The following table lists the default facts created by the PlateSpin Orchestrate Server for the User Grid object.
NOTE:Facts with mode dynamic are dyamic read/write facts, which means you can dynamically change the values for that fact.
Facts with mode r/o have read-only values, which means they can be viewed but changes cannot be made.
Facts with mode del are deleteable, which means they can be deleted at any time.
Table 4-16 User Facts
The following diagram illustrates the relationship between the User object facts and other Grid objects. It also shows the relationship between other discrete Grid object facts and the User object itself.
Figure 4-10 User Fact Junctions
Table 4-17 User Group Facts
The Matrix object has an associated set of facts and constraints that define its properties. The PlateSpin Orchestrate Server assigns default values to each of the component facts, although they can be changed at any time by the administrator, unless they are read-only.
The following table lists the default facts created by the PlateSpin Orchestrate Server for the Matrix Grid object.
NOTE:Facts with mode dynamic are dyamic read/write facts, which means you can dynamically change the values for that fact.
Facts with mode r/o have read-only values, which means they can be viewed but changes cannot be made.
Facts with mode del are deleteable, which means they can be deleted at any time.
Table 4-18 Matrix Facts