| 1 |
Well bug 44132 [1] has been a real thorn in my side for some time. The |
| 2 |
problem being that all mpi implementations currently in portage block each |
| 3 |
other. This is a real pain for any serious administrators, makes testing |
| 4 |
new/other implementations too time-consuming, and in my opinion has probably |
| 5 |
slowed any progress related to getting cluster applications into portage or |
| 6 |
the overlays. |
| 7 |
|
| 8 |
All that being said, I set out to do something about it. Donnie Berkholz was |
| 9 |
nice enough to help me out early on and ended up suggesting that I look |
| 10 |
at crossdev. I shamelessly ripped off the aforementioned script and tuned |
| 11 |
it for mpi implementations and packages. It should be noted that all the |
| 12 |
changes I've implemented do [should, hopefully will] not effect the way the |
| 13 |
packages behave now, rather it just adds another option. The idea is as |
| 14 |
follows. |
| 15 |
|
| 16 |
sys-cluster/empi: Does the same stuff that crossdev does. You create a new |
| 17 |
implementation root by specifying a name and mpi implementation package to |
| 18 |
build it with. [2] Empi adds these to an overlay under a new category with |
| 19 |
the name you gave. The ebuilds inherit mpi.eclass which handles pushing all |
| 20 |
the files to /usr/lib/mpi/<name>, and providing files for eselect-mpi. |
| 21 |
|
| 22 |
Later, you can add packages by specifying the category name and packages to |
| 23 |
install. Empi grabs the ones that inherit mpi (including deps), adds them to |
| 24 |
the overlay and emerges. The deps stuff hasn't been tested all that much. |
| 25 |
|
| 26 |
app-admin/eselect-mpi: Used to setup a user's environment to call a named |
| 27 |
implementation install. Basically does this by dropping a bash-sourceable |
| 28 |
file in ${HOME}/.env.d/mpi. The not-so-fun part is that the user then has to |
| 29 |
remember to source that file. Also used a fair amount by mpi.eclass. |
| 30 |
|
| 31 |
I threw some quick notes showing commands and output up in my devspace. [3] |
| 32 |
If anyone is at all interested, please try this out and let me know what you |
| 33 |
think. Even if you don't try it out but have ideas/comments/rants, I'm all ears. |
| 34 |
|
| 35 |
Current overlay has the following ready to be tried out. |
| 36 |
eselect-mpi/eselect-mpi-0.0.1 |
| 37 |
sys-cluster/empi-0.1 |
| 38 |
sys-cluster/hpl-1.0-r3 |
| 39 |
sys-cluster/lam-mpi-7.1.4-r1 |
| 40 |
sys-cluster/mpi-examples-1.0 |
| 41 |
sys-cluster/openmpi-1.2.5-r1 |
| 42 |
|
| 43 |
A couple of final words, hpl and mpi-examples currently wouldn't work without |
| 44 |
empi, mainly because I'm lazy :) Also I still haven't figured out a good way |
| 45 |
to handle do{man,doc,www} etcetera, ideas are welcome. There's still a fair |
| 46 |
amount of work to be done, but I wanted to see if anyone had any feedback |
| 47 |
regarding the general concept first before pushing on. |
| 48 |
|
| 49 |
You can pull the overlay from rsync://cold-front.ath.cx/mpi (for now...) |
| 50 |
|
| 51 |
Thanks, |
| 52 |
|
| 53 |
|
| 54 |
[1] http://bugs.gentoo.org/show_bug.cgi?id=44132 |
| 55 |
[2] Currently openmpi-1.2.5-r1 or lam-mpi-7.1.4-r1 |
| 56 |
[3] http://dev.gentoo.org/~jsbronder/README.empi.txt |
| 57 |
|
| 58 |
-- |
| 59 |
Justin Bronder |
Archives