From: Erwin.Laure@cern.ch on behalf of Erwin Laure [Erwin.Laure@cern.ch] Sent: Friday, November 15, 2002 9:43 AM To: Bob Jones Subject: Re: Input for follow-on project Hi Bob, For the R&D part of the proposal we could also add "performance engineering" issues; this would include data access optimization along the lines of what Kurt is doing now (I think, this work was originally not planned within EDG?) but also new areas like performance modeling & prediction which ideally should integrate with the high level application layer to enhance scheduling. In your R&D list below there is a large part devoted to different porting activities -- I'm not sure if EU eager to support projects that focus too much on maintenance and porting. Cheers, -- Erwin Bob Jones wrote: > > Hi, > Here are a summary following the ATF discussion during lunch. Note I > have not used the ATF list for this because I would prefer to restrict this > msg to EDG internal people only - so please send your replies to me and I > will report on them collectively at the next ATF. > > Your input is requested for the follow-on project after DataGrid taking into > account your experiences (good and bad) from dataGrid. Below is a summary of > the points we already mentioned at lunch but please expand/correct as you > see fit. > > The 6th framework proposal (http://egee-ei.web.cern.ch/egee-ei/) identifies > 2 arms to the project: > > - "production infrastructure" providing a production style grid facility for > application groups (science & industry) > > includes: > hardware for grid sites and manpower to run them > access to high-speed network > deployed middleware (presumably based on some version of EDG from 2003) > end-user support group (including production of end-user documentation, help > line, FAQ, bug-reporting etc.) > some equivalent of the Loose Cannons to help user groups port their > applications to the grid > training: equivalent of EDG tutorials (i.e. dedicated manpower to support > it) and for grid site managers. > Grid monitoring center (monitors status of grid and individual sites) > > application groups: need some well defined application groups (as in EDG) > but also need to include industrial applications and allow new application > groups access to the grid to understand how they can make use of it. We need > some mechanism where we can allow users access to the grid without being > project partners (but within what limits, entrance criteria etc.) or having > their own hardware to make grid sites. > > - "research and development" addressing extensions to the middleware > > General approach: can't ask to redo what was already done in EDG. This also > means we should not say "EDG failed to deliver a working widget so we will > do it in the new project". But we can use the approach of building on > experience and data from dataGrid to address new areas. New areas include: > > - porting mware to OGSA > - security issues > - high-level application layer (links together existing mware modules) > - porting to further platforms not foreseen in EDG > Should avoid including still very far off research subjects that will not > make their way to the production testbed within 3 of years. To support R&D > activities, we need to include: > - provisions for a development testbed > - resources dedicated to integration, testing and verification > - existence of an architecture group > - training for developers on tools and techniques used within the project > > We need emphasize building on the iterative process setup in dataGRID that > allows feedback from end-users on the application testbed to the developers > working on the future middleware releases. > > Cheers, Bob.