SRM Collaboration

Conf call minutes

May 25, 2005

Attendees: Michael, Bryan, Andy (Jlab), Timur, Rob, Jon (FNAL), Alex,
Arie, Kurt (LBNL), Owen (RAL), Peter, Olof, Benjamin (CERN)

Arie: 1) LCG's "parallel SRM" activity is complementary and reasonable.
LCG needs to define own feature for LCG purpose. Not really conflicting
with our SRM activity. 2) There seem to be a need to accelerate v3 for
LCG. 3) V3 is not a lot of new different functions: maybe only discovery
and features sets. No real differences from v2 to v3.

Olof: Jean-Phillip is part of LCG, not me.

Peter: not me either.

Arie: LCG Jamie's conf call and workshops are good. It's good to put
together such activities for experiments and collaborations. Let's
accelerate on V3. I think we can finish it in a month or so if people
are willing to help reviewing the draft spec.

Andy: A couple issues: 1) v3 is a new functional definition which is not
backward compatible. 2) Functional and operations specifications are
both needed.

Arie: Splitting functional and operational spec is because accommodating
framework changes, such as WS and WSRF.

Alex: Different operational frameworks are not going to be compatible,
and we need to agree on a particular operational framework to ensure the
compatibility and interoperability, at any one time. If someone
implements "experimental" operational spec, then they need to provide a
thin layer or something that can accommodate SRM implementations.

Peter: We have some experience with that. The latest gSoap and Axis seem
to work well. Security is another concern for the compatibility in
different implementations. WS-I (ws-i.org) is a good way to go from our
experience. Authorization/ACL is another concern.

Arie: Is Jlab's v3 a different new version?

Andy: it mainly affects operational spec.

Arie: we're not going to have backward compatibility if we do not do
anything.

Timur: we can have more service pointers for different versions.

Andy: that's not backward compatibility

Arie: What's your (Andy's) view on v.1, v.2 and v3? How to bridge
between different versions?

Bryan: During the overlapping period, we'll provide two versions on
different ports.

Andy: LCG is talking about SE and OSG is doing similar but seems
different.

Owen: RAL has some experiences with v.2.1

Peter: Current position of LCG is v.1.1 as common denominator

Rob: OSG is also v.1.1.

Arie: If space reservation is important, then v3 is a way to go

Olof: Yes, v3 is the way to go. We talked about this issue in the last
Sept. meeting, but nothing has been done yet: Granularity in the space
reservation. Being able to reserve continuous spaces is needed. The
inability to do that is a problem in v2 space reservation.

Timur: Issues of space reservation on disk cache. Each implementation
should have a global reservation module.

Rob: Largest file size can over-expose the underlying storage. Could be
exposing too much details.

Arie: Even if size is provided by the time putting the file, global
reservation is done already and maybe it's too late.

Olof: need some hint. Don't have control over how much user puts into
the space either.

Arie: need some penalty for such misbehavior.

Timur: maybe need some estimated file sizes instead of max file size.

Andy: this space reservation is an adv. feature in v3 that each group
can have different modules to accommodate different arguments.

Arie, Rob: Don't want to go that way. If CMS and ATLAS version of space
reservation is different, it is a problem.

Arie: Question from Olof is valid. If added in v3 as an array of
estimated sizes, storage system can come back to honor or come back
saying "can't do". What will prevent to a user from asking always the
max (penalties or incentives)?

Olof: In our case, incentive is getting your reservation

Arie: array of estimated file sizes to be added to the space reservation
could be good.

Olof: next issue is permission and ACLs. Now we have unix type
permissions. When ACL comes, what is it to be?

Arie: ACL becomes important. AuthZ by VO is done, and how to interact
with SRMs? Don't know. We'll need all these at some point, but not in
v3.

Owen: next issue -- 'prepareToGet" to return the result right away for
files already available vs. an extra status calls. If there are files
available, returning right away saves time and can imply less security
implications. Extra status call includes new security handshaking and
efficiency matters too.

Arie: This is a general issue because don't have callback

Olof: yes, returning right away could be useful

Timur: returning right away may cause TURL stuck in the disk cache until
unpin comes in. We are limiting how many TURLs that user can have, and
controlling the network bandwidth.

Arie: That's your implementation choice.

Alex: for returning request result right away, you don't have to return
TURLs for every available file . If you want, you can limit this
according to your network policy or the user quota.

Peter: maybe we need extendTURLLifetime or something similar

Arie: We purposely stayed out of these things. Let them release the
files explicitely. The penalty is not getting your files fast enough if
there is no release. You need some lifetime on files.

Peter: Semantics of the interface is needed, preferably with use cases

Arie: you mean the document spec should contain some use cases?

Peter: furthermore, every method in the spec should have some use cases

Arie: how about having weekly meeting to stabilize v3?

Timur: as we implement v2.1, we have some issues to discuss as well.

Arie: It seems that Calls every other week should be sufficient. I'll
schedule bi-weekly conf calls. Discussion issues should be sent to the
mailing list ahead of time.