Graeme, these are all sensible ideas but I suspect that if the
experiments were in a position to deliver drop in web services then they
could be deployed now as generic (or specific) middleware services. The
truth is more likely that they have scripts/crons/daemons not web
services. 

John

> -----Original Message-----
> From: Testbed Support for GridPP member institutes 
> [mailto:[log in to unmask]] On Behalf Of Graeme Stewart
> Sent: 21 September 2005 15:36
> To: [log in to unmask]
> Subject: Re: [TB-SUPPORT] GridPP, GridSite and VO Boxes [Fwd: 
> Service Hosting (was Re: VObox)]
> 
> On Tuesday 20 Sep 2005 13:05, Andrew McNab wrote:
> 
> > I'd be very interested in direct feedback and ideas from the GridPP
> > sites about this, so we can accomodate them in the way GridSite
> > implements things.
> 
> Andrew,
> 
> I think this is the most helpful thing I've read in the VO 
> box discussion. I 
> think that as we have not yet deployed VO boxes to any great 
> extent (are they 
> even at the T1s yet?) now is the time to agree on a 
> _sustainable_ model for, 
> let's call them, "grid service extensions".[1]
> 
> Much of the site's problems with VO boxes stems from having 
> shell access - 
> people are rightly nervous of this in the context of being 
> able to invoke 
> almost arbitrary services on a known end point (as opposed to 
> a worker node, 
> which has quite different properties, e.g. no inbound IP).
> 
> Remove this, and provide service containment, and I think 
> there's a lot less 
> to fear from these services.
> 
> Would a workable model be something like:
> 
> 1. Each site has a VO box, for containerised VO services. 
> Include a local 
> mysql install to hold state, revision and configuration 
> information for each 
> service (sites could move this to a central database service 
> if they want).
> 2. Each VO produces a set of service RPMs to be installed on this box 
> _by_the_site_ (have a meta-package, like lcg-VO-ATLAS, and 
> YAIM can do the 
> right thing.)
> 3. Configuration is held in the database. VO nominated 
> manager's certificates 
> can modify the services' configuration.
> 4. Through web services or GRACE technology the services are 
> then accessible 
> to a larger number of users (i.e., the VO users). 
> 
> gLite FTS is a good model of how to do this - administration 
> takes place 
> through the web service, secured by a grid certificate, as 
> well as normal 
> service access.
> 
> In this model the VOs do not get login access to the box - 
> they don't need it. 
> The deployed services become more difficult for hackers to 
> exploit because of 
> the restricted containers they run in. Logging of usage is 
> trivial, through 
> the web server.
> 
> It even then seems good for the middleware, rather than 
> boding ill for it:  
> LCG can then present this as a sustainable model of VO 
> "extensions" on the 
> grid.
> 
> What we ask the experiments for is to swap some of the 
> laissez-fair of the 
> current proposal for a more sustainable model. Keep the sites 
> happy and it 
> will mean less work for the VOs in the end.
> 
> Cheers
> 
> Graeme
> 
> 
> [1] I don't want to be too general in the discussion here, 
> but... Obviously 
> general services should be provided by generic middleware; 
> however, there are 
> many problems that probably can't be solved easily just by generic 
> middleware. Also, although there are some arguments being put 
> that VO boxes 
> are a temporary nasty, I believe that once they are in place 
> it will be 
> terribly difficult to remove them.
> 
> -- 
> --------------------------------------------------------------------
> Dr Graeme Stewart              http://www.physics.gla.ac.uk/~graeme/
> GridPP DM Wiki         http://wiki.gridpp.ac.uk/wiki/Data_Management
>