It is possible to describe relationships between requirement sets in a fashion similar to characteristics (Section 5.6). If each requirement in ReqsA is a subset of at least one requirement in ReqsB, then ReqsA⊆ ReqsB. This is expressed in Equation 6.6, and also as the Haskell function isReqSetSubset in Appendix C.11.
ReqsA⊆ ReqsB , ∀ri ∈ ReqsA∃rj ∈ ReqsB∧ ri ⊆ rj (6.6)
A ⊆req B , A.reqs ⊆ B. reqs (6.7)
DB/A ReqsB
ReqsA
RA⊆reqRB
Figure 6.2: Overlapping requirement spaces for RA and RB where RA⊆req RB.
In practice, however, this definition is not useful. This is based on the fact that a dimension with no requirements is equivalent to a requirement for that dimension which will compose with any resource, regardless of whether or not that resource is defined over that dimension. It is worth noting this is in contrast to an unspecified value requirement which requires any characteristic in the dimension, but forbids a candidate resource with no characteristics in that dimension. The effect of this is that a resource A with a subset of the requirements in B, as defined by Equation 6.6, may define a subset of acceptable values over the dimensions shared with B, however it will accept any values over all undefined dimensions. If B contains requirement dimensions not found in A then B may be more restrictive, meaning over these dimensions A defines a superset of acceptable values (noted as DB/A in Figure 6.2).
As Figure 6.2 illustrates, knowing a candidate resource satisfies the requirements of A provides no knowledge as to whether it satisfies the requirements of B (given A ⊆reqB), and vice versa.
A simple example of this is shown in Listing 6.1, where A ⊆req B. This example shows how the relation ⊆req provides no insight into the matching of candidate
6.2 Requirement Sets 119
<A >
< reqs >
< mhz match = " >= " > 2000 </ mhz >
< ram match = " >= " > 512 </ ram >
</ reqs >
</ A >
<B >
< reqs >
< mhz match = " >= " > 1500 </ mhz >
< ram match = " >= " > 256 </ ram >
< s t o r a g e match = " >= " > 500 </ s t o r a g e >
</ reqs >
</ B >
<C >
< chars >
< mhz > 3200 </ mhz >
< ram > 1024 </ ram >
< s t o r a g e > 200 </ s t o r a g e >
</ chars >
</ C >
<D >
< chars >
< mhz > 1500 </ mhz >
< ram > 256 </ ram >
< s t o r a g e > 1000 </ s t o r a g e >
</ chars >
</ D >
Listing 6.1: The shortcoming of the ⊆req relation is shown by this example. A ⊆req
B however this provides no additional information about A or B’s abil-ity to match resources which the other has matched.
resources C and D, where C satisfies A but not B, and D satisfies B but not A, so there is no transitivity of the ⊆req relation.
It is exactly this issue of undefined values which introduces the significant com-plexity of tri-state logic into the Condor ClassAds Matchmaking mechanism. All logical operators relating characteristics within the “self” ClassAd (equivalent to the base resource in the RESTful model) to the “other” ClassAd (equivalent to the target or candidate resource in the RESTful model) must cater for the condition of the “other” ClassAd not defining that attribute (i.e. characteristic), and the inter-pretation of that condition. It results in the creation of new logical operators is and isnt and a correspondingly more complicated set of truth tables for what are otherwise well known logic operations. Furthermore, given the user constructs the logic statement for the requirements, it is necessary to add a fourth condition to the result of all logical operations: error.
6.2.1 Requirement Space
A variation in the requirement subset definition can address this shortcoming by introducing the concept of requirement spaces. Equation 6.8 defines the relationship A ⊆rs B which specifies that resource A has a smaller (i.e. more restrictive) require-ment space than B, meaning DA.reqs⊇ DB.reqs(A has the same or more requirement dimensions compared to B) and over every shared dimension DA∩B (which is equiv-alent to DB) the requirement value space is the same or smaller for the requirements from A compared to those from B. Figure 6.3 illustrates this, showing the require-ment space of RA as a subset of RB. Under this condition, any resources with characteristics which satisfied ReqsA would also satisfy ReqsB, therefore it can be inferred that any resource which composes (one-way) with A would also compose with B. This is described formally in the Haskell function isReqSetRSSubset found in Appendix C.11.
ReqsA ⊆rs ReqsB, ∀rj ∈ ReqsB∃ri ∈ ReqsB
∧ ri ⊆ rj∧ DA.reqs ⊇ DB.reqs (6.8)
RA⊆rs RB , RA.reqs ⊆rs RB.reqs (6.9)
6.2 Requirement Sets 121
RA ⊆rsRB
ReqsB
ReqsA
Figure 6.3: Nested requirement spaces for RA and RB where RA⊆rsRB.
6.2.2 Multiple Requirements Within the Same Dimension
It is possible to have multiple requirements on the same dimension. Figure 6.4 illustrates this. In this case it is possible that one characteristic will satisfy multiple requirements, or that each requirement in the same dimension will be satisfied by different characteristics. Figures 6.5, 6.6 and 6.7 illustrate some of these cases. For the requirement set to be satisfied, it is simply necessary that each requirement be satisfied by at least one characteristic, rather than every characteristic in that dimension having to satisfy all in-scope (i.e. same dimension) requirements.
0 0
Figure 6.4: Two requirements in the same dimensions, collectively defining a fixed range of acceptable characteristics, and therefore each satisfied by the same characteristic cx2. Also, cx4 satisfies rx1 but not rx3.
6.2.3 Multi-dimensional Requirement Sets
The union of all requirements defines the overall acceptable multi-dimensional value space for a compositional candidate resource. Figure 6.8 illustrates two requirements in two dimensions. The requirement rx3 in dimension x (interpreted as “char < x3”)
0 0
Figure 6.5: Two requirements in the same dimensions, defining mutually exclusive ranges, however each is satisfied by a different characteristic. rx2 by cx1, and rx4 by cx5. cx3 does not satisfy either of the requirements.
Figure 6.6: Two requirements in the same dimensions, with overlapping value spaces. rx1 is satisfied by {cx2, cx4} and rx3 is satisfied only by cx4.
Figure 6.7: Two requirements in the same dimensions, with overlapping value spaces, but only one requirement, rx1 is satisfied by cx2, while rx3 is unsatisfied.
is satisfied by {cx1, cx2} but not by cx4, and the requirement ry2 in dimension y (in-terpreted as “char > y2”) is satisfied by {cy3, cy4} but not by cy1. Note that the intersection of these two dimension axes is for illustrative purposes only, commu-nicating the concept of orthogonality of dimensions. There is no fixed intersection point, and, in this context, no concept that characteristics in dimension x are related