It might reflect their use better if they were simply listed as ‘optional pools’ instead of secondary and primary. The current naming suggests preference from the job’s perspective - as in ‘primary is preferred, but if not available, use secondary’.
Opinions?
I suppose the primary/secondary naming is really more from the Slave’s ‘viewpoint’, since it checks for work based on Primary pools first, then secondary ones…
To be honest, we never really put that much thought into the naming, that’s just what we were calling it while we were implementing it. Now that I think about it, you might have a point, ‘optional’ might be better, and I think “alternate” would be good too. I’ll have a talk with Ryan when he gets back, see what he thinks 
Yeah alternate is even better.
While on the subject, it would be GREAT if jobs could actually have a primary / secondary pool from the “jobs” perspective… That way we could prioritize jobs so that they prefer certain machines, but if those are not available, however reluctantly, but go onto their secondary choice machines.
+1 for both ideas. 
Hmmm, that’d be a little tricky to do with the way Pools are intended to work, since Slaves aren’t really “in” Pools. Jobs, really, are the things that are “in” Pools, which allows an individual Slave to prefer certain Jobs over other Jobs based on their Pools.
To make Jobs prefer certain Slaves over other Slaves would probably be a Group thing, the way I see it. We’re definitely overdue for overhauling the way Groups work, and I believe this is on the roadmap as part of the whole scheduling redesign we want to do.
I don’t know if that made any sense, but either way, we’ll try to keep that use-case in mind when redesigning the scheduling
Makes perfect sense! Whether they are pools or groups, or even a new entity, i don’t really mind, the main thing is the ability to define a preference list for machine set for the job.
thanks!
l