Re: [easybuild] easybuild new user experience

[Olav Smørholm]

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.MMDD but any kind of tag will 
> > just do.
> >  >
> >  >Then you might create symlinks like:
> >  >  /opt/apps/sandybridge -> /opt/apps/*.MMDD
> >  >
> >  >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}/MMDD )
> >
> >??
> 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
> 

Re: [easybuild] easybuild new user experience

[Jack Perdue]

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.MMDD but any kind of tag will just 
do.
  >
  >Then you might create symlinks like:
  >  /opt/apps/sandybridge -> /opt/apps/*.MMDD
  >
  >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}/MMDD )

??

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.

($.02)

jack

RE: [easybuild] easybuild new user experience

[Cook, Malcolm]

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.MMDD but any kind of tag will just do.
 >
 >Then you might create symlinks like:
 >  /opt/apps/sandybridge -> /opt/apps/*.MMDD
 >
 >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}/MMDD )

??

 ~Malcolm

Re: [easybuild] easybuild new user experience

[Ward Poelmans]

On Wed, Feb 11, 2015 at 2:32 AM, Stuart Barkley  wrote:
> I've been looking at easybuild for a little while now and it appears
> to be a suitable framework for a good portion of our needs.

Welcome to EB!

> My cluster does not have direct access to the Internet so I can't use
> any of the automated download procedures.  I actually consider this a
> feature in that I eventually know exactly what software is running and
> that nothing was downloaded and installed that wasn't intended.

What is stopping your users from copying other software to your
cluster and running it? Or using a ssh portforward/socks proxy to get
internet on your cluster?

> Dependencies/source package downloads:
>
> I think I eventually used "--dry-run --robot" and grepped the output
> to determine the full dependency lists and create individual 'eb
> --stop=fetch --force' commands for every package dependency.  I also
> used something like this to determine an internal build order so I
> didn't need to --robot 50 packages which would all churn and fail on
> the same dependency.

We could create an `--fetch-only` option that doesn't stop on a failed download.


> Some questions:
>
> How do people deal with software with frequent updates (java) or
> security issues?  Do you rebuild and remove old packages?

For the security sensitive package, we use the OS provides ones
(openSSL, glibc, ...) and let the OS update them.



> Is there any planned support (or something I'm missing) for allowing
> someone else to use an existing easybuild installation (including
> toolchains and other packages) to build a test/prototype package?  I
> would like to have other staff be able to build local test packages
> off of the production toolchains and be able to give me a set of
> proposed/working .eb files for final build.  This is similar to the
> above beta question, except I don't expect others to be able to
> maintain their own easybuild installation (and don't want them writing
> into the production installation).

You can use a different `-installpath=` for the test packages? If the
production toolchains are in the module path, they will be used.


> Wish list (maybe for hack-a-thon):
>
> Don't automatically create $HOME/.local/easybuild (or any other top
> level directory).  Too many times I forgot to specify my configuration
> file name or fumble fingered something and ended up with a mess of
> files where I didn't intend.  Requiring the top level directory to
> already exist prevents a misconfigured easybuild from writing a bunch
> of stuff for later cleanup.  The error message should be clear about
> the directory name so that a simple copy/paste can be used to create
> the missing directory when it is truly missing.

I don't agree here. Almost all Linux programs will create their own
directory under $HOME without asking. It's the proper thing to do. If
you have troubles forgetting the specify certain options, add them to
the config.cg file? Or export them as bash variables if the change
from location to location.


> Process for removing a package.  It is probably fairly simple, mostly
> deleting the installation tree and the modules files.  Dependencies
> might be tricky (indicating all the dependencies and refuse to remove
> would be fine).

This is on the wish list for quite some time:
https://github.com/hpcugent/easybuild-framework/issues/1000

Ward