"Lengyel, Florian" <[EMAIL PROTECTED]> schrieb am 04/07/2008 02:26:15 AM:
> "The point is, if you installed the software yourself, you know where it > is and don't really need a Grid-wide service to find it. On the other > hand, if you didn't install the software, then it is either system > software, so again you don't need to query for it, or you can't trust > the installer to have done it in the exact way you would need it and to > keep it so over time. In case you trusted the installer, you would have > been informed by her how to find and use this software (e.g., what sort > of specifications to include in your jobs to make sure they execute > properly)." > > > This should not be a matter of trust, and it looks like an opportunity > for automation. When I was consulting at Merrill Lynch, I had to determine > which library and header files were used to build various programs. > In cases where I had a makefile, I redefined the CC macro to > a PERL program I had written, called "woe" for "where on earth." > This generated a report of the locations of header library files that would > have been used by the compiler and linker if I were building the project. > Of course operating systems attempt to locate needed libraries and programs > at runtime. This is at the level of the workstation. Asking your local > sys admin will not scale to the level of the grid (or the virtual > organization). How about asking your VO sys admin? This is how it works in our project. I agree that some level of automation is needed. Thanks to Charles Bacon for pointing out softenv/modules. We've been basically using something like "source $DGRID_VO_DIRECTORY/wisent/env.sh" to ensure a uniform environment in every supported cluster, but the mentioned solutions have the advantage of being public and thus likely to be already known by other administrators. > Speaking of interacting with the grid using familiar OS shell > commands, I might > want something like a /dev/grid-disk, which I might install as a > kernel module using insmod... I've been pondering this, too, but I came to the conclusion that offering a POSIX API (which I think you mean by a grid-disk device) makes the most sense if you have fast disks connected with a fast, reliable network, using some automatic data replication scheme. It is less feasible if you have lots of tertiary tape storage accessible over a WAN (as is common (?) today) because the acceptable use patterns and failure modes are so different from a normal disk. I think there is a FUSE-GridFTP integration project on sf.net, which goes into that direction, but then GridFTP is quite possibly the wrong protocol for efficient block-level data access and it says nothing about data replication. There is also s3fs, which provides a FUSE wrapper for Amazon S3. I vaguely remember that it might have become infeasible after Amazon's change in their billing policy. Regards, Jan Ploski -- Dipl.-Inform. (FH) Jan Ploski OFFIS Betriebliches Informationsmanagement Escherweg 2 - 26121 Oldenburg - Germany Fon: +49 441 9722 - 184 Fax: +49 441 9722 - 202 E-Mail: [EMAIL PROTECTED] - URL: http://www.offis.de
