I haven't noticed any problem, but then all of my "PriorityWeight" factors are all 0, so I'd expect the multifactor plugin to keep all the job priorities at 0. In that case there shouldn't be any control lost by Moab.
I really don't need the priority change, I'm mostly interested in the utilization tracking. Any other drawbacks? ----- Gary Skouson -----Original Message----- From: Moe Jette [mailto:[email protected]] Sent: Thursday, June 06, 2013 2:06 PM To: slurm-dev; Skouson, Gary B Subject: Re: [slurm-dev] Plugin compatibility The problem is that sched/wiki2 sets all job's initial priority to zero (held) and then releases the jobs when Moab determines it's time to start the job. priority/multifactor is going to alter priorities by its own rules. Basically Moab loses control over the jobs in the configuration that you describe (you might as well just remove Moab and sched/wiki2). Quoting "Skouson, Gary B" <[email protected]>: > > Looking through the documentation, the priority/multifactor plugin > says it's incompatible with the sched/wiki2 plugin. I understand > about the prioritization stuff not working with the wiki plugins, > but I was hoping to use the accounting information that's available > from sshare etc. to watch utilization by different accounts and users. > > Looking through the code, I didn't see anything specific that was > going to cause problems, so I removed the check from read_config.c > and restarted schedctl with both the wiki2 and the multifactor > plugin enabled. Things seem to work as I'm used to, but now the > sshare info gets updated like I wanted. The external scheduler > still schedules jobs as it used to. > > Is there somewhere the incompatibilities are explained before I > cause myself problems? > > ----- > Gary Skouson >
