Scheduling policies can be applied into two phases of a scheduling cycle: match phase and allocation phase.
In match phase, scheduler prepares candidate hosts for jobs. All jobs with the same resource requirements share the same candidate hosts. The plugin at this phase can decide which host is eligible for future consideration. If the host is not eligible for the job, it is removed from the candidate host list. At the same time, the plugin associates a pending reason with the removed host, which will be shown by the bjobs command.
Finally, the plugin can decide which candidate host should be considered first in future.
The input/output of this phase are candHostGroupList and PendingReasonTable. Candidate hosts are divided into several groups. Jobs can only use hosts from one of candHostGroup in the candHostGroupList.
The plugin filters the candHostGroups in candHostGroupList, removes the ineligible hosts from the group, and sets the pending reason in the PendingReasonTable.
Since each plugin does match/sort based on certain resource requirements, it decides which host is qualified and which should be first based on certain kinds of resource requirements. The scheduler organizes the Match() and Sort() into the handler of each resource requirement.
After the handler is created, all that plugin needs to do is to register it to scheduler framework. Then it is the scheduler framework's responsibility to call each handler doing match and sort and handling each specific resource requirement.
When the plugin registers the handler, a resource criteria type is associated with the handler. The Criteria Type indicates which kind of resource requirement the handler is handling.