Hi Malcolm,
On Feb 13, 2015, at 8:01 PM, Malcolm Cook <[email protected]> wrote:
> 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?
They _could_ ;-)
> 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?
Yeap, that’s exactly the idea.
We can argue forever about the exact naming, but the logic is what you
confirmed here.
It gives you the (sometimes needed) freedom to reuse buildsets across archs.
fi. theoretically, you could switch to 32bit modules/builds, from 64bit,
keeping the same namespace (it’s case-specific if that makes any sense;
yet now you _can_ shoot yourself in the foot, with 1 cheap symlink update!)
Best of all, rollback is dirt cheap. Roll-forward for testing? no problem.
N.B. At build time the paths are always explicit (HPCBIOS*YYYYDDMM);
it is modulefiles that point to them that make the scheme work.
modulefiles are accessible via symlinks (or farms thereof).
> 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?).
IMHO, Gnu Stow solves a different problem (when you need to consolidate
multiple /bin, /lib, /usr );
it could be applied to provide for “single-modulefile-bundles” but this is a
totally different use-case,
which only matters when you need to a) reduce length of *PATH* or, b) make
bundled module loads atomic.
In practice, I have never done any scheme more complex than HPCBIOS.YYYYDDMM?,
where “?" denotes a node class, because that proved to be sufficient for
clusters
that have passed from my hands. YMMV. Yet, you may implement any scheme ad
infinitum.
I know that our fellows from Vienna had to deal with many platforms and OSes,
at once,
so they may have some insight to offer about their naming practices. However,
my stance is that naming practices will be keep changing as systems change...
... while the tag approach of YYYYDDMM? is meant to keep carrying meaning in
the future.
> 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.
Hard fact of life is, we only know if something is “over-designed” after having
applied a technique over multiple years (and sites). Then it’s clear what could
have been thrown out. But in engineering we need provision & safety margins
anyhow,
even if they are never entered to (and sometimes rightly so).
cheers,
Fotis
--
echo "sysadmin know better bash than english" | sed s/min/mins/ \
| sed 's/better bash/bash better/' # signal detected in a CERN forum
