Hi,
be careful.
the job needs to see the exact same list of grid clients everywhere. or
at least (in the rosy future) the APIs with which the progr has been
linked must work everywhere.
Also there needs to be some basic set of things available. Python &
Perl + the standard suite of unix v7 / SysV / whatever tools should be
there.
However there is an awful long way between this and "identical
environments". And if we expect identical environments it will all fail
too.
JT
Burke, S (Stephen) wrote:
> LHC Computer Grid - Rollout
>
>>[mailto:[log in to unmask]] On Behalf Of Ake said:
>>This is just bullshit. This is GRID remember? Not "uniform bunch of
>>PC's" What about AIX system or SGI's or what have you... (i know they
>>are really rare at the moment but i also know that they are slowly
>>coming closer)
>
>
> If a job *needs* a particular OS it should be able to select it with a
> requirement (although the question about how the OS is named still seems
> to be rumbling on without a conclusion). However, it's likely that a
> command like lcg-cr would be available on pretty much any OS. Similarly,
> java and python at least should be able to work with anything. IMO the
> point of the Grid is exactly the opposite: from the POV of a job the
> environment *must* look the same on every site, or at least on a few
> broad classes of site. If jobs need to deal specifically with 200
> separate configurations it's hopeless, that's exactly the situation the
> grid is supposed to get us away from.
>
>
>>Expecting a certain set of RPM's (or packages in general) beyond the
>>basic unix functionality is simply wrong.
>
>
> If people take that view the grid will fail.
>
>
>>Anything else should be advertised (as Runtime Environments) from the
>>system and used in selecting which host to run on BEFORE entering the
>>system.
>
>
> That's totally impractical. Are you going to publish the entire RPM list
> as an RTE and have requirements 500 lines long? (Apart from anything
> else people are currently complaining about RPM lists being published as
> a security hazard.)
>
> Stephen
|