Hi Malcolm, Jack, >> >Then you might create symlinks like: >> > /opt/apps/sandybridge -> /opt/apps/*.YYYYMMDD >> > >> >I used a dubious example name above but you get the idea.
Something that has functioned in practice before is a scheme like: /opt/apps/HPCBIOS.haswell -> /opt/apps/HPCBIOS.YYYYMMDD-h /opt/apps/HPCBIOS.sandybridge -> /opt/apps/HPCBIOS.YYYYMMDD-s /opt/apps/HPCBIOS.YYYYMMDD-h /opt/apps/HPCBIOS.YYYYMMDD-s /opt/apps/HPCBIOS.YYYYMMDD-h /opt/apps/HPCBIOS.YYYYMMDD-s [.. ..] ie. letters h, s, etc denote node classes which can be treated as a single family. I think that if you run out of 26 letters, you are a cloud provider, not HPC site ;-) A nice advantage of the above design is that it becomes tractable to deliver the software trees via packages (fi. rpm), which is not possible in some other ways. On Feb 11, 2015, at 5:09 PM, Cook, Malcolm <[email protected]> wrote: > Fotis, I note your example name, "sandybridge", apparently encoded an intel > processor microarchitecture, NOT the name of a linux distribution (such as c6 > or c7 for releases of centOS, as proposed). I'm trying to understand the > implications of possibly needing to support a heterogeneous environment > having multiple CentOS versions (6.5 and 7.x) on multiple core types > (sandybridge) and would appreciate any more clarity here. Are you possibly > suggesting that buildsets for each combination of microprocessor and OS > version might be appropriate > (provoking visions of /opt/apps/{sandybridge,Nehalem}/centOS{6,7}/YYYYMMDD ) Yes, technically that is both feasible and cheap (kudos to easybuild for that). In practice you only need a subset of the combinations, as per your site’s reqs. Then, you can use your traditional OS’s configuration management system to have a symlink farm pointing to where each case should have a default, as buildsets advance in time and improve. Shoot for both agility and stability! On Feb 11, 2015, at 5:30 PM, Jack Perdue <[email protected]> wrote: > We certainly have need for such a thing. Our cluster is mostly Ivy Bridge > (with AVX2 support), including the login nodes where I do most my builds. > However, we have some systems (1-2TB) with older chipsets that don't > have AVX. So anything built with optarch=True (i.e. -xHost) on the login > nodes won't work on the big mem nodes. Been there done that; the above design should handle this fine. Sometimes you have the opposite problem: a newish shiny fat node basically requires custom optimised builds. Still, solution is the same! > I could do the build on the big mem (older chipset) nodes but then won't > get the benefit of AVX on the newer nodes. So somehow providing a way > to distinguish based on the chip set would be kind of nice. Once upon a time, the famous “target” strings of fi. GCC did the job well: x86_64-redhat-linux ## 10 years ago, this was mostly sufficient Such names, would be great for symlink farms on buildsets for various nodes. However, on HPC platforms the situation is nowadays more complicated because architectural families of CPUs require very customised builds w. explicit names. enjoy, Fotis -- echo "sysadmin know better bash than english" | sed s/min/mins/ \ | sed 's/better bash/bash better/' # signal detected in a CERN forum
