We’ve got situations where we need to have slaves automatically blacklist themselves from certain jobs (in cases where their environment or software configuration is improperly configured, etc.). Since this needs to be possible from anywhere (including a shell script), the simple approach at first would seem to be to use deadlinecommand. Unfortunately:
deadlinecommand is slow.
The Blacklist is a list, but deadlinecommand only supports setting job values outright, so there is no way to perform an atomic “append” to the “ListedSlaves” property.
At this point, I’m basically stuck with shelling out to mongo manually (which I think will let me do what I need), or writing a more Deadline-centric py-mongo wrapper (which I’ll probably end up doing anyway at some point). However, I’m curious if deadlinecommand is going to get any love during the D6 beta cycle.
Also, I searched through the API docs, but couldn’t find a way to add a slave to a job’s machine list (or set the “White” property) from the context of a running plugin, but I thought I’d check and make sure I didn’t something that was staring me in the face…
That would be great, thanks. To expand on that a little bit, it would be great if the functionality was generic, so it could be applied to any job property.
We have to handle the machine limits a bit different, because they are actually just specialized Limits under the hood.
For the other job properties, all of them are already available through the scripting API. I guess you were referring to the command line specifically?
Well, unless I’m overlooking something, I don’t there is currently any way of making an atomic append to any list-type job property without going directly to Mongo.
Right, there isn’t an atomic operation that does this for any list-based properties. You would have to have an instance of the job object, append to the list, and then save the object.
Sorry, I should have phrased that better. I was wondering if it would be possible to genericize the atomic append operation so it could be used with any list-type job property, instead of only implementing it for the machine list.
We can add this to the wish list. I think making it generic should be possible for the other job properties, but if I recall there aren’t too many that are lists, so worst case we need to handle each one specifically.