[gin-data] RE: [gin] Re: [gin-info] Dane's question

[Jensen, J (Jens)]

Hi Erwin, & al,

Taking your example of SRM, I see SRM 1 as a subarea
of "SRM" which in turn is a subarea of gin-data.

I suggest we should collect for each area/subarea:

	(a) available services, as Dane suggests,
	(b) "standard" tests, for minimal interop (example below),
	    and
	(c) dependencies between areas (e.g. storage depending
	    on information publishers), or subareas,
	(d) the results of the testing (a) with (b).
	(e) perhaps people interested in the area/subarea.

Returning to the SRM (version 1.1) example for now (and keeping
it brief-ish), (a) will list a set of "volunteer", non production,
servers.  (b) will list necessary tests, including:

1. Testing the gridftp server with globus-url-copy;
2. Testing the srm with dCache srmcp (which doesn't
   depend on information system), upload/download,
3. 3rd party copy between SRM1s with srmcp,
4. LCG tools like GFAL or lcg-* which *do* depend
   on the information system.

These tests are necessary but not (necessarily) sufficient: other
major Grids who are using SRM 1 may contribute other "minimal"
tests.  I can think of more advanced tests of SRM1, too.

(c) will highlight that some tests may depend on gin-info tests.

(d) is for keeping track of which version was tested with
what; which version of client tools and peer servers.

(e) above may be useful because sometimes it's useful to
ask other people to test your latest SRM1 from their own
Grid.  So say LCG develops a new SRM1 and we ask someone
from OSG to test it.

Grids not using SRM 1 will not be interested in the SRM1
subarea, until we aim for higher hanging fruit and other
islands, etc.  By then, the information gathered by the
(e) people will become useful.

Most grids using specific services will already have basic
tests for their services that they can contribute.

Back to the specifics, we have had good experiences with wikis
- I don't know pragma - any solution that lets (authenticated)
users relatively easily update web pages will be useful.

My £0.02.

Cheers,
				--jens


-----Original Message-----
From: owner-gin at ggf.org [mailto:owner-gin at ggf.org]On Behalf Of Erwin
Laure
Sent: 10 March 2006 08:23
To: Jennifer M. Schopf
Cc: gin-info at ggf.org; gin at ggf.org; Papadopoulos Phillip
Subject: [gin] Re: [gin-info] Dane's question


Hi Jen,

Yes, eventually we need to have a system like the ones you describe 
where the agreed subset of information is published.

However, for now we need to start collecting the information on the 
sites taking part in the exercise in a more pragmatic way to enable the 
subgroups to start working. For instance, the data mgmt group needs to 
know which SRMs and gridFTP servers are to be used for interoperability 
tests. I think we need to proceed in parallel here.

Cheers,

-- Erwin

Jennifer M. Schopf wrote:
> I think the agreement was actually to look into ways to describe the 
> data, the PRAGMA tool was one possibility, WebMDS was another, several 
> folks said they had available ways to display the data.
> 
> However, listing services IS NOT something this list has discussed yet- 
> we're still trying to reach an agreement on a minimal set of attributes, 
> so i think we'd need more info about what you're looking for.
> 
>  -jen
> 
> 
> 
> At 08:24 08/03/2006, Erwin Laure wrote:
> 
>> Hi Dane,
>>
>> (putting the general gin list in cc)
>>
>> I think one of the outcomes of our Athens meeting was to use a webpage
>> for that, probably hosted by pragma. Phil?
>>
>> Cheers,
>>
>> -- Erwin
>>
>> Yuji Saeki wrote:
>> > I forward mail from Dane.
>> >
>> > Yuji
>> >
>> > -------- Original Message --------
>> >
>> > To: gin-info at ggf.org
>> > From: Dane Skow <skow at mcs.anl.gov>
>> > Subject: An Info Service listing the GIN early adopter resources ?
>> > Date: Tue, 7 Mar 2006 22:21:40 -0600
>> >
>> > We have created a VOMS services for GIN early adopters so that we can
>> > identify people working to debug the interoperation separately from
>> > the full production VO lists in use on the various grids. I find
>> > myself wanting to find the equivalent for services. How shall we
>> > manage the list of services which are intending to make themselves
>> > available for GIN access ? Is this sensible or will it always be
>> > pairwise ?
>> >
>> > Should we use some common info service (or tag in existing service
>> > descriptions) to indicate services which are intended for InterGrid
>> > use ?
>> >
>> > A webpage may be the simplest thing and sufficient for a while...
>> >
>> > What should we do for now ?
>> > Dane
>> >
> 
> 
> 
> Dr. Jennifer M. Schopf
> Scientist                              eInfrastructure Policy Advisor
> Distributed Systems Lab       National eScience Centre and JISC
> Argonne National Laboratory  The University of Edinburgh
> jms at mcs.anl.gov                 jms at nesc.ac.uk
> http://www.mcs.anl.gov/~jms http://homepages.nesc.ac.uk/~jms
> 
>