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 >>classad >> >>[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. >> >>Steve > [...] > 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: STARTD_EXPRS = MachineClass, $(STARTD_EXPRS) Once I did this the job was picked up and ran as expected. --Mike
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature