Hi Graeme,
what do you mean low volume? low internet traffic? not cpu intensive?
small disk space required? low maintainance? really high trust?
Although I haven't seen any of the experiments giving any explanation yet,
I think that since we have started to ask loudly for explanations we have
gained 2 things:
1) A well written policy
2) The most appalling requests have been dropped, I would say overnight.
We still have to discuss the operational part and I still have massive
reservations on the long term because I believe that once these machines
are in place we will never get rid of them. Nobody will do anything to
insert the software as a general grid component.
cheers
alessandra
On Wed, 21 Sep 2005, Graeme A Stewart wrote:
> 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 Alessandra Forti *
* Technical Coordinator - NorthGrid Tier2 *
* http://www.hep.man.ac.uk/u/aforti *
********************************************
|