|
From: | Michel Courtine |
Subject: | Re: GNU Parallel host sticky jobs - a first proposal |
Date: | Fri, 31 Oct 2014 09:18:46 +0100 |
Hi,I truly believe this is an important feature to implement as it is quite simple, completely generic and seems to be an obvious need in many user scenarios to me.I finally realized parallel is written in perl and all the source code stands in one file. Silly me. I was expecting some c code.I must admit my perl is quite rusty, haven't used it much since university but I could dig into it a bit if you give me some guidance.I had a very quick look at the code and it looks like the host list is held inside Global::host so it shouldn't be too hard to add a list of tags to it. But we still need to define a cli syntax for it.I quite like the 4/sshstring syntax. What about adding a second optional slash with values separated by comas?Old fashion, of course still compatiblehostnameuser@hostname4/hostnameOptional new fashion4/iOS,Android/hostname18/Linux/hostname28/OSX/hostname316/Emscripten/hostname4I am less sure about the right way to tag the jobs though. Use the same syntax?iOS/irAndroid/arLinux/lrOSX/orEmscripten/erThis would invalidate the '/' in the input sources though. Not an issue for me but could probably be an issue for other users.parallel -j 1 --verbose --tag --filter-host \--basefile ./ci-builder --basefile ./utils --return {} --result ./logs/ \--sshlogin 4/iOS,Android/hostname1 \--sshlogin 8/Linux/hostname2 \--sshlogin 8/OSX/hostname3 \--sshlogin 16/Emscripten/hostname4 \"TERM=xterm;SHELL=/bin/bash;PATH=/usr/local/bin:$PATH;export BUILD_PROJECT_NAME=$BUILD_PROJECT_NAME;export BUILD_PROJECT_URL=$BUILD_PROJECT_URL;./ci-builder" ::: \iOS/ir \Android/ar \Linux/lr \OSX/or \Emscripten/erI would then expectir to be sent to hostname1ar to be put on hold for ir to completelr to be sent to hostname2or to be sent to hostname3er to be sent to hostname4Optional BehaviourOne important option that seems to make sense is a 'strict-stickyness' which is the behavior described abovei.e. if a job requires a tagged host and all these tagged nodes are busy, the job is put on hold, waiting for the one of the tagged hosts to free up.It would be nice to be able to disable the strict aspect of stickyness so a job would then go to the next available node regardless of tags.Error HandlingThe only new kind of errors that is introduced is a mismatched label defined on the jobs that is not defined on the hosts. I think the script should simply abort at launch with a nice error messageAdditional pointAt the moment, the jobs seem to be distributed in a random manner, I think it would be nice to add an option to make the job submission order stick to the sshlogin orderWhat do you think?Best Regards,M--
[Prev in Thread] | Current Thread | [Next in Thread] |