[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Condor-users] Condor-G matchmaking



Hi,

In order to assure correct matching between
jobs and resources, it would help if one
could put a "hold" on the negotiator.

I am thinking about the following scenario:

1. Two long jobs, each requiring N CPUs
   are submitted. Assume the job classad
   have both
       Requirements = TARGET.FreeCPUS >= N

2. The scheduler triggers a negotiation cycle.

3. There is a resource which has exactly N free
   CPUs.

4. Job 1 is matched and will be sent by the
   scheduler to the Globus resource.
   Say it will reach the resource at time T

5. The resource sends a classad at time t < T

6. The resource classad arrives at the central
   manager and -- either because a new job 3 arrives,
   or the negotiator interval has elapsed -- a new
   negotiation cycle occurs which matches job 2
   against the same resource with the N CPUs
   (the negotiator is oblivious, and the resource
   classad can't know that job 1 is en-route)


Result: job 2 is incorrectly sent to the resource whose N CPUs will be allocated to job 1

This can be avoided if one could configure
the negotiator so that after a negotiation
cycle it is put on hold until it receives
a release command.

Is there a way to get this behavior?


Thank you. Gabriel Mateescu