On Wed, Feb 11, 2015 at 10:30:30AM -0600, Jack Perdue wrote: > On 02/11/2015 10:09 AM, Cook, Malcolm wrote: > >Hi Fotis & Stuart, > >.... > >>>What do people do/recommend for multiple OS environments? We are > > >> currently CentOS 6 but will eventually move to C7. I'm thinking I > > >> will want a separate application tree for each OS (/projects/app-c6 > > >> and /projects/app-c7). > > >> > > >> How do people deal with software with frequent updates (java) or > > >> security issues? Do you rebuild and remove old packages? > > > > > >You may be able to handle both of the above needs, > > >by using the concept of buildsets, mentioned in p. over here: > > > > >https://archive.fosdem.org/2014/schedule/event/hpc_devroom_hpcbios/attachments/slides/491/export/events/attachments/hpc_ > > >devroom_hpcbios/slides/491/FOSDEM14_HPC_devroom_09_HPC_BIOS.pdf > > > > > >In principle, the idea is that you create self-contained directory areas > > >with complete build trees, including modules, at a given point in time. > > >I've calling them /opt/apps/HPCBIOS.YYYYMMDD but any kind of tag will > > just do. > > > > > >Then you might create symlinks like: > > > /opt/apps/sandybridge -> /opt/apps/*.YYYYMMDD > > > > > >I used a dubious example name above but you get the idea. > > > >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 ) > > > >?? > 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. > > 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.
You can do this with modules, could have a look at how Lmod does this. -- Olav > ($.02) > > jack >
