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

Re: [Condor-users] pseudo-dedicated machine

Michael Thomas wrote:
> Steven Timm wrote:
>>On Wed, 7 Jun 2006, Michael Thomas wrote:
>>>I have a cluster of 50 nodes, 4 vms per node.  On all but one node I
>>>have a certain directory mounted via read-only nfs.  On the remaining
>>>node the directory is mounted read-write.
>>>Every user coming into the system only needs read-only access to the
>>>certain directory.  But one special user always needs read-write access.
>>>How can I guarantee that this special user always gets sent to the one
>>>node that has read-write access to this directory?  Note that I don't
>>>mind if other users also get sent to this read-write node.
>>First, define the one node to have an extra attribute in its machine
>>[root@fnpcsrv1 root]# grep IO /opt/condor/local/condor_config.local
>>MachineClass = "IO"
>>Class = "IO"
>>START = JobClass =!= UNDEFINED && JobClass == "IO"
>>On a non-grid job, then the user should just add
>>+JobClass = "IO"
>>requirements = (MachineClass =!= UNDEFINED && MachineClass == "IO")
>>to his condor submit file.
>>You can force a inbound grid job for that user to do that
>>by hacking condor.pm to add these extra two lines to the
>>submit script file it writes.
> But it seems that the job's requirements prevent it from running
> anywhere.  When I submit the job and run condor_q -better-analyze[1], it
> shows that the machineclass requirement is causing it to fail.
> How can I query the remote machine to verify that it's loading the
> condor_config.local settings as expected?
> --Mike

To answer my own question:

condor_q -startd -long <nodename> will list the parameters for the
compute node.

The reason the job was failing to match was because I needed to 'export'
MachineClass through STARTD_EXPRS:


Once I did this the job was picked up and ran as expected.


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature