Day 1

�Arie Shosani (LBNL)

�Alex Sim (LBNL)

�Andy Kowalski (JLab)

�Bryan Hess (Jlab)

�Chip Watson (JLab)

�Mark Ito (JLab)

�Michael Haddox-Schatz (JLab)

�Shaun De Witt (RAL)

�Owen Synge (RAL - over VRVS)

�Don Petravick (FNAL)

�Timur Perelmutov (FNAL)

�Eric Hjort (LBNL/STAR)

�Olof Barring (CERN)

�Peter Kunszt (CERN)

�Surya Pathak (Vanderbilt)

Welcome

Arie: go over his slides

1. File type must match space type that they are in.

Chip: global name mapping between local file system path name and srm site url. Ability to map from SURL to local file name is a requirement. Changing storage type on a file might affect on the TURL of the file or any transient states.

Arie: file type must match space type that they are in. So, TURL may change.

Peter. what�s important for client is if this call can be called or not. Prefer to limit core to core strictly.

Chip: If SRM supports durable, this SRM supports all types, not core for volatile and permanent, and advanced for durable only� but all spaces should support the same types.

Timur: systems should be able to choose. Disagree.

Arie: in reality with HPSS�� it should be separated� cannot� reserve on HPSS.

Chip: what does it mean by reserving 50GB on a semi infinite system?

Arie: Then uniform types for entire supported features�.?

Chip: that�s simple.

Arie: decide�

Timur: Q on space reservation. Do we know if it�ll be used for reading or writing? It�ll make a difference on our system

Peter: clients don�t care�

Don: write pool only applies to permanent.. space reservation applies to writes mainly.

Arie: 1. QoS. 2. On reserving a space.. which space to reserve� does it need to be reflected on the interface?

Chip: one name space in SRM is to be global to agree. That contains permission.

Peter: space management that Arie thinks about is in the staging area. But to me, it�s about where the file resides.

Arie: about file sharing�� SURL is the same for the two copies..

All: For some, the space is the total space in storage as such. Space reservations for these people would mean reserving total storage capacity for data.� For others, it is a concept inside the SRM like cache space and archive space. Space reservation would be tied to a space type, and there may be many 'spaces' that the storage exposes. CASTOR would never do something like that since this would mean micromanaging the internal staging area.

Arie: also notion of hierarchical storage, i.e. SRM as a front-end to a whole cloud of tertiary storage which may be anywhere also in the WAN.

then a prepareToGet will fetch the file into the SRM spaces from anywhere (even over the wide area).

All: WAN transfers are put not a get operations..!

Chip/Peter: staging from another SRM makes two SURLs

Don/Olof: in HSM systems, it�s true though. One SURL but two copies. �It�s LBL�s interest, but none of others have done any of this sort.

Chip: backend srm storage does not matter to client.

All: discussion on file sharing�� break time

Arie: there is confusion with TSPACE and S-SPACE. TSPACE by managed by client� because of the TURL. Spaces are global... we were focusing TSPACE.� We need to be clear.��

Chip: one use case that I have for metadata system.�� We need �is this file in cache or on disk� in the file metadata.

Olof: no t-space/s-apace..� confusing� all we need is an option that says the file is on the disk.

Chip: state of SURL being currently available is to be exposed � agreed by all.

Chip: can we have lifetime of the currently pinned file, along with currently on disk as boolean? Yes

Chip: srmLs only returns what�s in cache among the input array of SURLs. Some kind of qualifier is needed. And string contains regular expression. Wild cards (*) at least in srmLs only � agreed.

All: Type is an attribute of the file, for what SRM will do at the end of the lifetime. It has nothing to do with the where the file resides. �reservation� only applies to the disk cache without any space type associated with it because space is an attribute of the file. E.g. reserve a space, and put a file, and make the file as permanent.

All: no negotiation on permanent�� only negotiation is on the working space/cache space. No lifetime on the permanent files.� No starting time of the reservation.

Space does not have a type. Consider space as bank account, not a container.� Get rid of compact space, and keep releaseSpace only.

Lunch break

Olof: release with removal flag will remove a copy, not the SURL. It�ll remove only in your space (user space), not affecting the name space.

Arie: we need distinction between srm managed space and user space. We always had in mind about user space. Srm managed space is opening up a new area of confusion.

Olof: behavior of directory function is different from behavior on the space function. Spaces are owned by the SRMs, and users can work on the name space with SURLs.

All: prepareToGet should not have toSURL. TURL is only thing that�s returned by the SRM. Users cannot manage where the TURL stays. Same for prepareToPut. Users only manage SURLs in the global name space. Not the files in the user space, unless its SURL is on the global name space. SRM only to return TURL, not have users manipulate target directory space where the files go into (TURL).

Alex: functional spec overview

Alex: issues with op specs

Michael: Jlab version of op spec.�� Have SRM session maintained, and have additional command (subsequent function calls) to limit under the session. E.g. one called PUT, and then space type for permanent. Then all following function calls are limited to PUT/permanent. All optional features are valid within the session with session token.� In this way, server can only implement what it supports.�

Chip: it makes srm stateful, little different from request token. It makes context database.

Arie: this makes functional spec change a lot, by �use durable� etc within the session. We will need session token in addition. The whole architecture is hierarchical under a few set of functions, and detailed method needs to be defined by the features�

Michael: this is what WSRF does�� maintaining session id, and etc� pass session id every time.

Arie: this makes overloading functions with sessions. But session concept is much bigger. This idea does not force parameters to the interface level, but only put it into the server side specifics.� This is like having a request token, and decorate later on.

Chip: my preference is stateless.� Stateful (with request token) is not inside the session. Notion of stateful session is very dangerous.

Arie: two options. 1. introduce the session in the spec. 2. check every function and get request token and decorate the request. Then, we don�t have to maintain session token.

Peter: session is restricted to the single call, limited to 5 min, and set � and call.

Arie: #2 is okay..

Chip: every call involves srm server, and each call can be expensive.

Arie: do it on the request level, but not on the file level.

Timur: this is the way that wsrf does. Then why not just using wsrf ?

Arie: this affects functional spec not only on the op spec.� if not, we need to be very specific for every function.

Arie: how do we deal with this?

Chip: I still prefer keeping stateless as is�� not saying it cannot be done.. it slightly puts burdens on the srm server.�

Peter: it basically submits documents to its server. One task for 5 calls? It is kind of too much. Have sessions to make a document and pass the document.

Aire: have discovery function return xml schema�.

Peter: in that way, method signature does not change because the argument is the document, not parameters, even if new parameter is introduced.

Shaun:� On the http presentation

libCURL : http does parallel data stream

use http 1.1

LHC resource broker: gsi authenticated http by INFN italy

Day 2

�Arie Shosani (LBNL)

�Alex Sim (LBNL)

�Andy Kowalski (JLab)

�Bryan Hess (Jlab)

�Mark Ito (JLab)

�Michael Haddox-Schatz (JLab)

�Shaun De Witt (RAL)

�Owen Synge (RAL - over VRVS)

�Don Petravick (FNAL)

�Timur Perelmutov (FNAL)

�Eric Hjort (LBNL/STAR)

�Olof Barring (CERN)

�Peter Kunszt (CERN)

Don: presentation for OSG TG-storage meeting.

Don: started to put together a Glossary of Terms on which we could agree.

v Definition of terms for FILE properties :

� Retention:� volatile, permanent, durable

o permanent - the file has no expiration time

o volatile� - an expiration time exists and the storage may delete all traces of the file at that time

o durable�� - expiration time exists but the storage may not delete the file, should raise error condition instead

� Lifetime / Expiration time : lifetime is assigned to volatile and durable retention files but when asked, the system will return the expiration time in UTC

� Quality of Retention : is a kind of Quality of Service. It refers to the probability that the storage system lose a file, We recognize three levels, Replica, Output, and Custodial.� Numeric probabilities are self-assigned.

o Replica quality has the highest probablity of loss, but is appropriate for data that can be replace because other copies can be accessed in a timely fasion.

o Output� quality is an intermediate level and refers to the data which can be replace by lenghty or effort-full processes.

o Custodial quality provides low proabality of loss.

� Access Latency : Files may be Online, Nearline or Offline. These terms are used to describe how latency to access a file is improvable. Latency is improved by storage systems replicating a file such that its access latency is online.

o The _Online Cache_ of a storage system is the part of the storage system which provides file with online latencies.

o For the SRM we only keep Online and Nearline.

o For completeness, we also define Offline.

o Online Lowest latency possible. No further latency improvements are applied to online files.

o Nearline file can have their latency improved to online latency automatically by staging the file to online cache.

o Offline files need a human to be involved to achieve online latency.

v Definition of STORAGE properties

� Capacity : The storage has the notion of capacities that it can provide to the users. CASTOR and dCache storages we deal with have 'infinite' capacity.

� Quotas : The storage may provide a means to manage quotas, first with VO granularity

� Metadata : The storage exposes metadata like the access protocols provided, and their parameters, VOs supported etc.

All: space reservation should not exceed �quota�. Quota is through admin interface.

Arie: space type has no meaning since yesterday. How do we say where to put the files, $WM_TMP, $DATA, $SITE_READ, $SITE_WRITE?

Don: SRM cares about $SITE_Read/write.

Olof: Nick�s ppt presentation.� VO relative path in SURL will be from the configuration for now, until dynamic VO creation and those are available�� reserveSpace needs array of expected file sizes with how many files are to be expected for that size: pairs of <number of files, expected file size>

Eric: STAR SRM use case presentation

Arie: compatibility issue in v3 client talking to v1, v2, v3 servers, and v1 client talking to v.2 and v.3 servers. With translators� discovery retrieval such as getting end point�

Peter: slides

Have the srmCheckPermission to local only, no relay

ACL: owner, user list, group list. No others. RWX. File type ( file, dir, link)

Olof: slides.� Left-over holes from v.1.1 from last year ppt

On v3, Status code to be added for each method (function).

Use case for each function. Reusability of the TURL.

Separate Status code from error codes � all allowed status codes and error codes for request and for SURLs for each function

Conf calls: every 2 weeks and cut down to once a month if attendance is low

GGF:� produce core spec and submit

European effort: LHC effort � meeting to alternate so that different people can attend

Meeting: twice a year. Once in US and another in Europe

Next one at cern

Voting rights: deferred

Issues list by arie

1. session item

Core should not have any decoration methods

srmLs: additional decoration for advanced, but nothing for core

every core fuction will have a flag �decoration to come�. Request token will be used to maintain the session. Server can time out the session

2. http/gsiftp : make http and gsiftp as recommendation, not as a mandatory.

3. lifetime: there is file lifetime associated with file. There is pin lifetime associated with file moved into the cache space. Pin lifetime will be called expiration time. Lifetime will be end time in GMT time (UTC).� One more lifetime with TURL on prepareToPut.. want to call it transfer lifetime.� Need to complete the transfer within the transfer lifetime. Will be a duration.

4. should we have �pin� as a separate function? Advisory pin vs. mandatory pin?

5. issue of TURL metadata (timur): getTrnasferProtocol to return gsiftp plus its properties (service metadata).

6. we only have online and nearline storage types. If an srm has 5 different types of online, what do we do?

Summary by Peter

1. what types are spaces? permanent and volatile space..

a. spaces have no type. FILES have type, space just 'is'

b. only surl's have type. space has no type.

c. concept of types is only on files

2. quotas?

a. different admin interface is needed

3. TURL namespace management

a. restrict NS management to SURL NS

4. removing a file is a strong remove every pin will disappear.

a. all references will be gone

5. srm v3 client to access existing implementations

a. translator makes it look like a v3 server

b. then it can be a common component? Maybe

6. srm v1,2 clients talking to v3 server

a. can the srm endpoint be deduced from the SURL? Already in v2

b. if the host does not exist anymore? that is a problem which is not up to the SRM to resolve. the client will need to rename on its own

7. we don't expect v2 client to talk to v1, so this compatibility matrix is only valid for v3. hopefully v3 can stay for a longer term

8. security

a. VOMS accepted as baseline

b. CAS model rejected

c. agree that good implementations will allow for mapping callout

d. agree that read/write ACLs needed, with 'strings' that are adhered to in the SRM

e. these strings are the DN and the VOMS groups

9. Sessions:

a. Go for a model where we have 'decorations' that can be added to the core methods if advanced features are to be used

b. features are only to be used for decorations

c. there is a method for each decoration in advanced sets

d. core has a flag that says 'decoration to come'

e. for the purpose of avoiding overloading of methods, this is a clean solution

f. in terms of reuse of connection that is also a possibility

g. It is restricted to method 'overloading'.

h. model: core - no decorations but possible flag for 'decorationToCome'. all decoration methods are for advanced features.

i. decoration-ID is the request token

j. the server can time out this decoration if nothing happens

10. HTTPS and GSIFTP as default transfer protocols

a. having another protocol in addition to gsiftp would be useful for those sites who find gsiftp difficult to use

b. mandating it is a problem

c. we just make it a recommendation for implementation for have these two but not have it mandatory

d. if someone has only 'bbftp' say, that is fine

11. Lifetime

a. there is a file lifetime associated with the SURL (if its not permanent)

b. there is a pin lifetime for files moved into cache space

c. pin lifetime is from prepareToGet

d. on status report, you get back the expiration time (end time)

e. time zones: UTC

f. on prepareToPut there is a lifetime (transfer life time) which is the time until the put request's space will be available to the client.� This transfer time window should be reasonable

12. Pin separate from Request (explicit pin)

a. extend 'online' status of files independent of a request

b. discussion on whether this is useful or not

c. weight of pin would need to be taken into account?

d. who is allowed to do this pinning?

e. taken as 'advisoryPin'

f. maybe this is an admin method (VO admin)

13. Transfer URL metadata

a. in certain systems the number of streams may be limited

b. certain data can be accessed in one mode or another

c. this is service metadata actually, just like available protocol

14. Only two types of storage: online and nearline

a. if you have 5 types of online with different protocols etc. i have no way of knowing