The limit group logic seems to be kind of broken. We have two limit groups we would like to use for a job: Nuke and Nuke_i however every slave checks every limit group so our render nodes don’t render if they aren’t whitelisted in the nuke_i limit group.
My expected logic for a slave would be:
“Nuke_i, nope not whitelisted… moving on… nuke… stubs in use… 0 ok, I can join.” A workstation should go “Nuke_i whitelisted, Stub available… checking out.”
Hmm, I would have thought that it should check each group until it reaches the end of the list, or finds work to do. I will have to check on this.
Hello Gavin,
So I looked into this, and a machine must be part of all limit groups on a job in order to be considered for it, or it will be skipped. Limits are such that if you have, say, 3 limits on a job, nuke, 64bit, and 32gbram, then any machine that would do the job would have to be white listed in all three groups. Hope this helps.
Could this be changed in the future? We would like to track multiple limits on a single job across multiple computers. In this specific case we have a limit group for one license set and a second limit group for another license set.
That way we could have 3 machines check out a Interactive license and 1 machine check out a render node license without license failures.
Oh, I figured it out. I need to use the “Exclusion” list not the black/white lists.