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.