2.5 Understanding Job Examples

The following preliminary examples demonstrate how you can use JDL scripting to manage specific functionality:

For additional job examples, see Section 10.0, Complete Job Examples.

2.5.1 provisionBuildTestResource.job

The following job example illustrates simple scripting to ensure that each of the desired OS platforms are available in the grid and, if not, it tries to provision them. The resource Constraint object is created programmatically, so there is no need for external policies.

1  class provisionBuildTestResource(Job):
3      def job_started_event(self):
4          oslist = ["Windows XP", "Windows 2000", "Windows 2003 Server"]
5          for os in oslist:
6              constraint = EqConstraint()
7              constraint.setFact("resource.os.name")
8              constraint.setValue(os)
9              resources = getMatrix().getGridObjects("resource",constraint)
10             if len(resources) == 0:
11                 print "No resources were found to match constraint. \
12 os:%s" % (os)
13             else:
14               #
15               # Find an offline vm instance or template.
16               #
17               instance = None
18               for resource in resources:
19                      if resource.getFact("resource.type") != "Fixed Physical" and \
20                      resource.getFact("resource.online") == False:
21                      # Found a vm or template. provision it for job.
22                      print "Submitting provisioning request for vm %s." % (resource)
23                      instance = resource.provision()
24                      print "Provisioning successfully submitted."
25                      break
26               if instance == None:
27                      print "No offline vms or templates found for os: %s" % (os)

It is not necessary to always script resource provisioning. Automatic resource provisioning on demand is one of the built-in functions of the Orchestrator Server. For example, a job requiring a Windows 2003 Server resource that cannot be satisfied with online resources only needs to have the appropriate facts set in the Orchestrator console; that is, job.maxprovision is enabled as shown in the following figure.

Figure 2-16 Example of a Job to Provision Resources Automatically

This fact could also be set through deployment of a policy. If it is set up this way, ZENworks Orchestrator detects that a job is in need of a resource and automatically takes the necessary provisioning steps, including reservation of the provisioned resource.

Figure 2-17 The ZENworks Orchestrator Console Showing Virtual Machine Management

All provisioned virtual machines and the status of the various hosts are visible in this example of the Orchestrator console.

2.5.2 Workflow Job Example

This brief example illustrates a job that does not require resources but simply acts as a coordinator (workflow) for the buildTest and provision jobs discussed in Section 5.2, BuildTest Job Examples.

1 class Workflow(Job):
2    def job_started_event(self):
3       self.runJob("provisionBuildTestResource", {})
4       self.runJob("buildTest", { "testlist" : "/QA/testlists/production",
5 "buildId": "2006-updateQ1" } )

The job starts in line 1 with the job_started_event, which initiates provisionBuildTestResource.job to ensure all the necessary resources are available, and then starts the buildTest.jdl Example. This workflow job does not complete until the two subjobs are complete, as defined in lines 3 and 4.

If necessary, this workflow could monitor the progress of subjobs by simply defining new event methods (usually by convention using the _event suffix). The system defines many standard events, but custom events are simply the methods names custom_event. Every message received by the job executes the corresponding event handler method and can also contain a payload (Python dictionary).