Hi Jeremy, friends, romans, all, [not disjoint sets!]

The FTS bit in the beginning needs clarification.

The important point about "DPM client may work with dCache
server" is the MAY bit.  And it needs to be clarified
that it's the SRM 2.1 issue:

The DPM 2.1 clients were - obviously - written to interact
with DPM's 2.1 interface.

dCache will, we're told, have a 2.1 interface, expected mid
January.  

(As an aside, if dCache's 2.1 is delayed, we will be in trouble
meeting the 100% goal.)

Now will DPM's clients talk to dCache's servers?  Even if they
use the same WSDL, it needs to be tested, it is not unlikely that
there are interoperability problems.

It doesn't help that there are two different flavours of the
2.1 WSDL being used: 2.1.1 and 2.1.1-modified, the latter having
more soapy array handling than the former; the former uses the
old array handling (object) that we used in 1.1.

The problem is not with DPM, nor with dCache, nor is it DPM vs
dCache.  The problem is that 2.1 implementations are all either
relatively or very new, and we know from experience with version
1.1 that there will be interoperability issues to sort out
(in 1.1 we had GSI problems, and problems with srmCopy, and
more), and 2.1 is much more complex than 1.1.

Another potential problem with 2.1 is that the implementations
are unlikely to implement the full interface.  They will all
implement the basic stuff, get and put cycles.  But the more
exotic stuff, who knows.

Which is why I am emphasising FTS for the goals.  Because since
we will likely have to live with this for a while, something will
need to know how to talk to all of these (including the 1.1s because
some sites will probably not upgrade at the same time), and it seems
to me to be best if it's FTS.  As long as the GridFTP servers can
interoperate, but GridFTP is more mature than SRM 2.1.

FTS will, by the way, use service discovery to find out what it's
talking to, but can fall back to just trying it and be resilient.
Tasting which flavour it is, if you will.  That's the plan, anyway.

People who rely on srmCopy will be stuffed.  If you ask SRM A to
copy to SRM B, in all implementations AFAIK, A will assume that
B is a peer (same flavour).  Graeme tells me phedex can call FTS,
so CMS can have it their way too.

We should be able to start testing this by the end of the year with
the DPMs, transferring files from the dCache or DPM SRM 1s to the
DPM SRM 2s (or the CASTOR one when it goes online but we won't have
that at RAL this year).

Eventually the SRM 2s will converge (hopefully).  For DPM both
2.1.1 flavours are supported but I believe at compile time.

Yes, I know that wasn't the point of wsdl and service oriented
architectures and all that.  Welcome to the Real World (tm).

You may have heard of SRM 3; it is more than a glint in Arie's
[Shoshani, from LBNL] eye but is not finalised.  It is cleaner
than 2.1.  Doesn't help though because (1) experiments have
asked for 2.1 and (2) 2.1 does at least have a few implementations,
and (3) did I mention it was not finalised?

Of course I could be a pessimist and everything is delivered
on time and works perfectly from day 1...

Hope that helps clarify the issue.  If not, do let me know.

Thanks,
			--jens


-----Original Message-----
From: Testbed Support for GridPP member institutes
[mailto:[log in to unmask]] On Behalf Of Coles, J (Jeremy)
Sent: 15 November 2005 17:55
To: [log in to unmask]
Subject: Minutes from today's meeting


Dear All

Minutes from today's meeting are now available from the agenda page:
http://agenda.cern.ch/fullAgenda.php?ida=a056648

If you have any questions or comments please mail me or the list. The
only general follow up action noted was for all sites to ensure that
their site network contacts are aware of the SC4 data transfer testing
schedule outlined under item 1 of the agenda. 

I think the experiment snapshot presentations were useful but clearly
there is a lot more that all of us need to absorb. I encourage everyone
to spend some time looking at the TDR documents linked from here:
http://www.gridpp.ac.uk/deployment/links.html under "Experiment/VOs".
Also, in preparation for SC4 please be aware of the content of the talk
given by Jamie Shiers to the LHCC review today - it is linked to the AOB
item on the agenda. Finally, we are evaluating how to engage more fully
with NESC so any feedback you can provide on courses you would like will
be much appreciated.

The next UK wide meeting will be in mid-December. The exact date will be
circulated shortly.
Many thanks for your time and continued support.
Jeremy



Actions from the meeting:
O-051115-1 JC to forward sizing formula to list
O-051115-2 JC to feedback FTS upgrade issue to CERN team or BD to raise
on SC list
O-051115-3 Dteam to investigate methods to remove old transfer files
O-051115-4 JC Change At -> for in Milestone document
O-051115-5 Coordinators - Sites to warn site network contacts of data
transfer test schedules
O-051115-6 AF follow up on ATLAS numbers (number of jobs, how long jobs
run etc.)
O-051115-7 Dteam Follow up on CMS plans for file server requirements in
light of computing model
O-051115-8 JC to follow up on how sites are to know which experiment
software version to have installed
O-051115-9 JC to follow up on Vo published information. Sites would like
information on which VOs are active and more data on such things as VO
server, VOMS endpoints etc.)