Attending:
	John H, Ewan, Matt D, Duncan, John B, Brian, Matt M, Chris, Sam,
	Stephen, David, Govind, Jens

Apologies:
	Wahid

1. snoplus support

Would it be sufficient to have a UI at SnoLab and then use it to lcg-cr
files onto the grid?  Maybe, but would not get the benefits of scheduled
transfers with FTS.  Could we install the hardware and send it to them,
and have them take over the general maintenance (eg patching) of the
host system?  Or would there be considerable resources involved, eg more
than a disk server's worth of data?

If they have a dist'd filesystem we could propose to add a simple system
like StoRM on top of it, enabling us to transfer data at little extra
cost to SnoLab.  Or BeSTMan.

Size of data is ~10s of TBs, so not much, but other experiments are
expected to join later.

For comparison, previously, T2K used to scp stuff onto an SE, moving data
from Japan to IC where it was "imported" into the grid, then (grid) copied
to QMUL.  Now they have (we believe) a UI in Japan and lcg-cr the data.

Also, there will be the issue of certificates at SnoLab.

In increasing order of work (and usefulness??), the suggestions for
Snolab are:
1. Have a UI of sorts and GridFTP files across the pond.
2. Have a UI of sorts and lcg-cr files across.
3. Install a simple SE on top of whichever storage system holds the data -
   ideally on Lustre or GPFS.
4. Install a general purpose SE, like dCache.

We can suggest arranging a 1/2 hour EVO meeting with them if they want
to discuss the options - of course we will not in general be expected
to support storage at SnoLab.

What about custodial storage (aka tape)?  This would be at RAL T1, presumably.


2. DPM support discussion

Jeremy had circulated some notes to a handful of people, basically in
preparation for a discussion with the PMB.

As regards the need (or not) for the SRM interface, could we do without one
at the Snolab end?  Perhaps we don't fully understand the requirements to
be able to say whether we can meet _all_ of them on non-SRM infrastructure
(or half SRM half something else hybrid).  Of course FTS (or whatever is
used to transfer files will need to understand the protocols on both ends,
unless we have an intermediate staging area somewhere but that would be
bad, very.)

GPFS they can preallocate; Lustre cannot but can quota.  WebDAV on Lustre
might be an option (for Lustre sites).  FTS will need to support it.

In any case, we'd need a migration path of sorts to move from DPM to
DMLite, and/or to whatever else we choose to move to.  DPM should be
supported for the next 2 years, so we have time to figure it out.  We
also need to understand the risks, which means a plan of sorts.

3. Stress testing discussion postponed to next week.

4. KeyDocs - probably not much is missing in most of the docs, but maybe
   we should all help reviewing or something?

5. AOB

Sam had attended a meeting of sorts on "federation" with ATLAS.  DPM
redirection works, probably, but requires manual reconfiguration of
disk and storage.  Sam's almost got it working.

It used to require 1.8.3 but may now work with 1.8.2.


[10:05:00] Queen Mary, U London London, U.K. joined
[10:05:45] Sam Skipsey joined
[10:07:26] Ewan Mac Mahon Are you going to go for "Please install an SE for us", or "Here's an SE, please put it in a rack and cable it in"?
[10:07:41] Ewan Mac Mahon Also, how much space are we talking about?
[10:08:15] Jens Jensen More like "please install an SE for us" I think
[10:09:30] Stephen Jones joined
[10:11:58] David Crooks joined
[10:12:06] David Crooks Sorry I'm a bit late
[10:14:16] Govind Songara joined
[10:15:42] Ewan Mac Mahon Right; that makes sense. 
[10:16:34] Ewan Mac Mahon And on this same thing, can the FTS talk to a Classic SE?
[10:17:08] Sam Skipsey IIRC, the FTS needs to speak to an SRM.
[10:17:35] Sam Skipsey But anything with an SRM and a gridftp endpoint should work, I think.
[10:17:35] Brian Davies fts now works srm-less ( EOS )
[10:17:53] Sam Skipsey Oh, of course, I should have expected EOS to push for that.
[10:18:11] Sam Skipsey In that case: anything with an SRM+gridftp endpoint, or anything like EOS.  
[10:18:56] Ewan Mac Mahon Sp what does EOS use? Just plain gridftp?
[10:20:26] Brian Davies that's my understanding.
[10:20:27] Sam Skipsey I guess so. It does run a gridftp service.
[10:20:31] Stephen Jones I think a set of tiered options is required. From very simple and cheap and manual, to complex, expensive and automatic. Then let them choose.
[10:21:03] Ewan Mac Mahon Well, if the FTS can talk to a plain gridftp server now, then I don't think there's any point sticking them with the complexity of an SRM.
[10:21:18] Sam Skipsey I'd tend to agree.
[10:21:25] Ewan Mac Mahon You'd only bother if you had to.
[10:21:40] Ewan Mac Mahon So that's a technical question we need to settle.
[10:21:47] Stephen Jones Re: plain gridftp: yes; Keep it simple.
[10:22:18] Ewan Mac Mahon (Plus, does this mean we can FTS stuff onto NGS resources now   )
[10:23:22] Duncan Rand i thinkit will be the future because it will replace DPM as we know it
[10:32:18] Ewan Mac Mahon There's an extent to which if the lcg-utils could talk to WebDAV, then nothing would change.
[10:32:24] Brian Davies AFS?
[10:32:30] Ewan Mac Mahon SRM is somewhat an internal matter.
[10:32:42] Sam Skipsey AFS is really not designed to do what grid storage does.
[10:32:46] Ewan Mac Mahon @Brain: Arghhh
[10:32:59] Brian Davies globus-online  
[10:33:12] Sam Skipsey Okay, now you're just trolling!
[10:33:28] Brian Davies no I am not,
[10:37:59] John Hill left
[10:40:32] John Hill joined