Alessandra Forti wrote:
> Hi Graeme,
>
> I think that Andrew model is slightly simpler. Basically he is proposing
> a box were users can run their own cgi scripts as pool accounts, which
> is quite attractive for small things users might want to do, but I'm not
> sure how it would work if the experiments want to run databases or
> daemons like xrootd and they do want to do that.
Let's make a clear distinction between general high performance
components and service "extras". What I was proposing as a VO box does
low volume service extras. However, look at what Atlas want from a VO box:
https://uimon.cern.ch/twiki/bin/view/Atlas/DDMSc3#DDM_requirements_for_VO_site_box
and you'll see that it's pretty much that: a claims service running over
http(s) with a mysql backend and various other completely standard grid
tools (including gridsite!). OK, Altas say "No site admin intervention
should be required to upgrade versions of components". However, if they
make a meta-rpm and sites run "apt-get update" then Atlas will be in
control of the package versions.
CMS's need for a VO box seemed very modest too, easily taken care of in
this scenario.
Now, xrootd's clearly a different kettle of fish - but it's the only
proposed service which falls into this class, AFAICS. Then the answer is
easy: it becomes packaged by LCG and deployed at sites as a service
which experiments may or may not make use of. This is happening with the
LFC - avaliable everywhere, use it if you want to (Atlas and Alice will,
CMS and LHCb not). I can't believe that there are very many of these
type of services to deal with.
>
> What you are porposing is more in the spirit of EGEE grid. However if we
> go down this route it makes me wonder.... if it is so easy why do we
> need VO boxes at all and why do experiments insist on running their
> alternative services when they could run the grid ones.
>
My view (not speaking for any experiment of course!) the current
middleware does lack functionaliy, particularly in the data management
area. Experiments need ways of getting around this, ones which couple
far more specifically with their own DM systems. It's about providing
adden functionality to the existing middleware, which it may be hard to
do in a completely general way, or is being done too slowly. There are
holes, and actually if VOs fill them in novel ways (which we as sites
can handle in this sort of scheme) it will probably be a good thing for
the middleware and promote development, rather than hinder it.
Cheers
Graeme (in stragely optimistic mood...)
--
--------------------------------------------------------------------
Dr Graeme Stewart http://www.physics.gla.ac.uk/~graeme/
GridPP DM Wiki http://wiki.gridpp.ac.uk/wiki/Data_Management
|