2.3.1 provisionBuildTestResource.job

The following job example illustrates simple scripting to ensure that each of three desired OS platforms might be available in the grid and, if not, it tries to provision them (provided that a VM image matching the OS type exists). The resource Constraint object is created programmatically, so there is no need for external policies.

1  class provisionBuildTestResource(Job):
2
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 Orchestrate 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 Orchestrate Development Client; that is, job.provision.maxcount is enabled.

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

All provisioned virtual machines and the status of the various hosts are visible in the following view of the Orchestrate Development Client.

Figure 2-2 The PlateSpin Orchestrate Development Client Showing Virtual Machine Management

2.3.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 4.6, 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 so desired, this workflow could monitor the progress of subjobs by simply defining new event handler methods (by convention, using the _event suffix). The system defines many standard events. Every message received by the job executes the corresponding event handler method and can also contain a payload (a Python dictionary).