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.
Easybuild already has support for a lot of the packages we are
interested in running. I was also able to find answers to several of
my early problems in the mailing list archives so have been silent up
till now. The easybuild mailing list even had an important note about
a GPFS bug which I was seeing with easybuild which had also just
cropped up for one of our users in a different context.
At this point I've successfully built a large number packages of
interest to our user base (100+). I have yet to actually run any of
them except the build toolchains, that will be the next much more
careful and deliberate set of steps.
It has been a month or so since I last worked with easybuild, but I
wanted to provide some feedback before my memory of the new user
experience fades. Maybe some of these issues can be dealt with in the
hack-a-thon (I don't have any patches to supply at this time, sorry).
Initial bootstrapping:
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.
The initial bootstrapping process was a little awkward but I was
eventually able to succeed. I used bootstrap_eb.py in a VM to get an
initial installation to copy over to the cluster. Another part of my
bootstrapping involved alternately using easybuild to build 1.15.2 and
1.16.1. Easybuild is not able to reinstall itself (the install fails
when it deletes the currently running version) but each version can
build and install the other version.
Dependencies/source package downloads:
I continue to use the VM installation to download the necessary source
packages for things. Getting all of the dependencies for the large
number of packages I have built was a little awkward.
Fuzzy memory, but I think I had a number of times where I was
downloading things which are no longer there or require special
downloads and each time I fixed one problem I would get just a little
farther until the next problem download. It would be nice if
easybuild would continue processing after running into errors with one
package. Now that I have my local cache of the various distribution
files this is less of an issue since I will just continue to
accumulate files in $eb/sources.
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.
Some questions:
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?
Do people recommend updating toolchains and the dependencies (e.g.
eliminate multiple versions of python 2.7)? Since this will be our
initial build I don't really need python 2.7.3, 2.7.5 or .2.7.6.
Should I just use the --try options to build for 2.7.8?
What about toolchains? I patch OpenMPI for grid engine (information
from the mailing list, but not tested). Should I build this as a
custom toolchain instead of calling it goolf-1.4.10? Should I
consider trying goolf-1.5.X or 1.6 or is it better to stick with the
1.4 toolchains which most eb scripts use? I also just now see
information about the 1.7 toolchain, I need to review that email
thread.
Is there any planned support for beta/test packages? At the present
time I plan to have two separate easybuild installations and after
building/testing an application in the beta installation I'll rebuild
it in the production installation. (With C6 and C7 installations this
might multiply to 4 easybuild installations.)
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).
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.
Continue unrelated builds on a failure. 'eb --robot list-of-packages'
should continue to build what it can and it only needs to try to build
a dependency once.
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).
Thanks for the work on easybuild. This looks like it will address a
long standing need for building stable versions of software for our
users.
Stuart Barkley
--
I've never been lost; I was once bewildered for three days, but never lost!
-- Daniel Boone
