...
Job Package
If the job object could be thought of as a letter, with the type as the recipient, and the parameters as the address, the package may be thought of as the contentcontents.
Since each job type module is executed in exactly the same way by the Worker, there must be some way to communicate to the Worker how to execute the module in such a way that is specific to your needs. The package is how that is done. In general, the package is a generic data structure, included in the job object that can be accessed by the Worker's backend job module and used by that module to set up the job.
The size and contents of the job package will vary from job type to job typebetween job types. In the case of jobs submitted via qbsub, the package will likely contain a simple command in the package variable "cmdline." However, in the case of a sophisticated rendering application, the package may contain the name of the scene and dozens of global values specific to the job.
Job Agenda
The job agenda contains a number of discrete items–often frames–that items – often frames – that are transmitted by the Supervisor to the Worker on an "as needed" basis. The agenda usually contains a name, which is often sufficient for most purposes. Each agenda item can contain a package, much like the job itself.
Separating out the list of work to be done from the job itself at execution time can create a deal of improve efficiency. Workers can ask for work as quickly as they can complete it. If a worker Worker fails to complete a work item, it can be easily reassigned to another Worker. Adding more CPUs to a job simply increases the number of possible work items executed simultaneously.
...
The instance contains all the relevant information relating to the actual execution of the job. Virtually all information regarding job execution is in reality instance information.
Since the instance is a part of the job, the job acts as the clearing house for information about a job, including the instance. While that aspect of the job/instance relationship can sometime seem confusing, it becomes more evident with practice.
The best way to try to understand how instances relate to jobs is to work with them. The Worker will execute the instance by loading the type's module and running it with the appropriate package information.
All jobs must execute with at least one instance. Adding additional instance instances will cause the job to load the same module with the same package information.
Now, this is often a desired outcome. You may want to run the same command on each host in your compute farm. However, if you don't want the same job to execute multiple times, you probably want to consider using the agenda to give each instance a little something different to perform.