Hi,
>
> >> >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.
>
> Fotis, let's see if I follow you here...
This level of symlink indirection is providing for 'buildsets' whose name
encodes microprocessor-architecture and creation date of the buildset, only
one of which is 'current', right?
And, the '-h' and 's' _could_ be spelled out haswell and sandybridge, right?
So, if we wanted to also support OSX, cygwin (gasp), we could extend your
buildset scheme:
ARCHPATH=Linux/sandybridge # or Cygwin/64 or OSX/x86_64 as appropriate
/opt/apps/HPCBIOS/${ARCHPATH}/{YYYYMMDDa,YYYYMMDDb,etc}
and then for each ARCHPATH, track the 'current'
/opt/apps/HPCBIOS/${ARCHPATH}/current ->
/opt/apps/HPCBIOS/${ARCHPATH}/YYMMDDDD
Right?
If so, the part that nags at me, is handling common apps that either are
not compiled or whose compilation does not depend on this level of detail
(i.e. x86_64 is enough). Is that what you are suggesting (below) would be
handled the "symlink farm" (and, for this purpose, can you recommend Gnu
stow?).
Thanks so much for you insights. I am new to the administration side of
HPC. I may be "over-thinking" things. I welcome frank criticism.
Cheers,
~Malcolm
> 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
>
>
>
>
>
>
>
>
