Hi Olaf, On Dec 5, 2013, at 10:43 PM, Olaf Walter <[email protected]> wrote:
> But some questions remain, maybe you can give me some advice. Apart from the ML here, other EB users hang out on freenode in #easybuild. > > (1) choosing a (single) toolchain > We run a cluster for Bioinformatics software, with RHEL 6.4 and 10 GbE but no > Infiniband. If I understood correctly, goalf-1.1.0-no-OFED is the toolchain > of choice, right? You can use any toolchain for that matter, since most of the time the MPI configs either pickup IB automatically if it is present or you have to change configs to specifically link against IB libraries. There is no reason at all to not use multiple toolchains. Any of the one in EB should work out of the box, no matter which interconnect your cluster is using, but as said before you might need to tweak things in case some features are provided by the hardware are not used. It is best to check the resulting configure options for your MPI library to see if everything is built the way you want it to. > > (2) what if there is no eb for my toolchain? > I noticed that for some programs, there are no goalf-1.1.0-no-OFED > easybuilds. Amoung these, there are essentials like Perl. > I understand that there will be conflicts if users try load a goalf-based > module (say, Perl) and a goolf-based module (say Python) at the same time > (zlib). Would you recommend to build Perl with goolf-1.4.10, or to create a > Perl-5.16.3-goalf-1.1.0-no-OFED.eb myself? Maybe there is a reason that there > is no such easyconfig? Should I trust the --try-options? The goalf toolchain is more like a toy toolchain that should work on a wide variety of platforms. If there is config for a particular toolchain, you can either try using --try-toolchain=<toolchain>,<version> or you copy the configs and adjust the toolchain. Please not that dependencies are not automatically build with the toolchain and as such there might be some effort to build a dependency graph and rebuilt every package in there with --try-toolchain. Speaking of trust and testing things - well that one is tough and really depends on how you define trust. If compiles and executable can be started is good enough for you, then sure it is ready for consumption. A good idea is to ask application users or domain experts for which the application is installed/build to verify if everything works as expected. As usual YMMV … > > (3) OS Independence > Besides the fact that easybuild bootstraps its own compiler, it still uses > some OS ressources. For example, if I use GCC/4.6.3 to compile helloworld.c > on a compute node (with no development tools installed), ld complains about > crt1.o not being there. So I am wondering: To what extend are the resulting > packages OS-independent? If I build on RHEL 6.4, will they run on RHEL 6.3, > 6.5, RHEL 5 (or even Ubuntu)? Depends(™). For pure python packages this is for sure different than it is for C++ where no ABI standard exists and as such people depend particular compiler versions and the compiler implementation of name mangling etc. In general EL6 is a rolling release and the GCC version is kept at the same major release. Same goes for SLES. It also depends on how far you take it with eb, there is actually no reason not to roll libc and base libraries as part of dependencies if you want to take it that far. But a great thing about EB is that you can abstract most details in the config or in the block - things like what needs to be present as either system package dependency or EB dependency - and simply recompile! We have module/software trees for the following distros *EL6-based (CentOS6.x, RHEL 6.x - were we have 6.2/6.3/6.4 in use) *Ubuntu 12.04 *SLES11 (in use SP1,SP2,SP3) > > (4) Best practice for new releases > How would you deploy new releases of software, for example when a new release > of easybuild comes out? I decided that a new release would go into a new > EASYBUILD_INSTALLPATH, and I inform users to update their .modulerc to > contain the new modulepath. Is this what you would recommend? We handle that with environment variables as well, so we basically have a "production" directory and this is what our EASYBUILD_INSTALLPATH points to, but this is just a symlink to a directory that just contains the date - like 24-04-2013. -> production -> 29-04-2013 -> 10-09-2013 -> 02-12-2013 And then we just let production point to any one of them. Greetings, P > > Best regards, > Olaf > > R&D IT > Bayer Business Services GmbH > BBS-ITS-R&D-HealthCare Research > 13353 Berlin > > Geschäftsführung: Daniel Hartert, Vorsitzender | Wilhelm Oehlschläger, > Arbeitsdirektor > Vorsitzender des Aufsichtsrats: Werner Baumann > Sitz der Gesellschaft: Leverkusen | Amtsgericht Köln, HRB 49895 > > > > >
