SRM v2.2 Changes
From SRM v2.1.2
Compiled by Alex Sim at LBNL
Last updated : December 15, 2006
Abstract
In regards to recent discussion with WLCG Data Management Coordination Group for the requirements of the LHC experiments of the Grid Storage Interfaces, we made changes to the SRM v2.1.2 specification. The changes are based on the 2-day meeting in May, 2006.
This SRM version 2.2 changes extend and update the SRM v2.1.2 specification.�
WSDL Finalized : June 20, 2006
All changes after the above date will be grouped separately from page 5.
V2.2 Changes
1. In general
2. In the Defined Structure:
3. In the Space Reservation Functions:
4. In the Permission Functions:
5. In the Directory Functions:
6. In the Data Transfer Functions:
7. In the Information Discovery Functions:
8. All
Changes after June 20, 2006
8.1. July 3, 2006
8.2. July 6, 2006
8.3. September 27, 2006
8.4. December 15, 2006 (includes contributions from Flavia Donno)
o From srmGetRequestID to srmGetRequestTokens
o SRM_FILE_BUSY is added
o SRM_FILE_LIFETIME_EXPIRED is added
o SRM_REQUEST_INPROGRESS is returned at the request level and file level.
o A comment of �Operation on the path such as browsing the top directory may be prohibited� is added to the SRM_INVALID_PATH.
o SRM_REQUEST_INPROGRESS is returned at the request level and file level.
o b) will be changed to OUTPUT or CUSTODIAL retention quality space, from durable or permanent space which no longer exists as definitions.
o If space is being released with forceFileRelease option while SURLs are being created with srmPrepareToPut or srmCopy, the file is removed and SRM_INVALID_PATH must be returned by the srmPutDone,� srmStatusOfPutRequest, or srmStatusOfCopyRequest when the file is volatile. If the file is permanent type, the file is moved to the default space, and the space would be successfully released. The subsequent srmPutDone, srmStatusOfPutRequest, or srmStatusOfCopyRequest would be successful.
o If space is being released without forceFileRelease option while SURLs are being created with srmPrepareToPut or srmCopy, SRM_FAILURE must be returned in srmReleaseSpace.
o If requestToken is not provided and SURLs are provided, then the SRM will release all the files specified by the SURLs owned by the caller, regardless of the requestToken.
o If requestToken is provided and SURLs are not provided, then the SRM will release all the files in the request that is associated with the requestToken.
o At least one of requestToken and SURLs must be provided.
o If requestToken is not provided, then authorizationID may be needed as an additional verification method for the client authorization to release files.� It may be inferred or provide in the call.
o srmReleaseFiles is only valid after srmPrepareToGet or srmBringOnline operations. To release TURLs after a srmPrepareToPut, srmAbortRequest or srmAbortFiles must be used. If a client submits srmReleaseFiles after srmPrepareToPut or srmPutDone, then the SRM server returns SRM_INVALID_REQUEST.
o This method allows to change only one lifetime at a time (either SURL lifetime by the newFileLifetime or pin lifetime by the newPinLifetime), depending on the presence or absence of the request token. SURL lifetimes are on SURLs that resulted from the successful srmCopy or srmPrepareToPut followed by srmPutDone, and pin lifetimes are on TURLs or file copies that resulted from srmPrepareToGet, srmPrepareToPut or srmBringOnline
o When the requestToken is provided, only pin lifetime is extended with newPinLifetime.
o When SURL lifetime is extended with newFileLifetime, the request token must not be specified.
o When lifetime input parameters (newPinLifetime or newFileLifetime) are not specified, the SRM server uses its default value.
o Lifetime cannot be extended on the released files, aborted files, expired files, and suspended files. For example, pin lifetime cannot be extended after� srmPutDone is requested on SURLs after srmPrepareToPut. In such case, SRM_INVALID_REQUEST at the file level must be returned, and SRM_PARTIAL_SUCCESS or SRM_FAILURE must be returned at the request level.
o If input parameters newFileLifetime or newPinLifetime request exceeds the remaining lifetime of the space, then SRM_SUCCESS is returned at the request and file level, and TSURLLifetimeReturnStatus contains the remaining lifetime.
o Lifetime extension must fail on SURLs when their status is SRM_FILE_BUSY.
o SRM_INVALID_REQUEST is added at the file level.
o If input parameters newLifetime request exceed the remaining lifetime of the space, then SRM_SUCCESS is returned at the request and file level, and TSURLLifetimeReturnStatus contains the remaining lifetime.
o Lifetime extension must fail on SURLs when their status is SRM_FILE_BUSY.
o arrayOfSURLs are optional. When SURLs are not provided, all files in the space must have the new extended lifetimes.
o This method applied only to SURLs, and output parameter pinLifetime in TSURLLifetimeReturnStatus must be null
o Output parameter, lifetimeGranted is clarified as it is relative to the calling time.
o includes SRM_REQUEST_INPROGRESS as a valid return status.
o Data type of input parameter desiredLifetimeOfReservedSpace is corrected to be int.
o Optional input parameters in TTransferParameters may collide with the characteristics of the space specified. In this case, TTransferParameters as an input parameter must be ignored.
o description about the unusedSize is added.
o SRM_EXCEED_ALLOCATION is added at the space level.
o srmRm will remove SURLs even if the statuses of the SURLs are SRM_FILE_BUSY. In this case, operations such as srmPrepareToPut or srmCopy that holds the SURL status as SRM_FILE_BUSY must return SRM_INVALID_PATH upon status request or srmPutDone.
o srmSetPermission will modify permissions on SURLs even if the statuses of the SURLs are SRM_FILE_BUSY.
o srmMv must fail on SURL that its status is SRM_FILE_BUSY, and SRM_INVALID_REQUEST must be returned.
o If input parameter desiredTotalRequestTime is 0 (zero), each file request will be tried at least once.� Negative value is invalid.
o Output parameter remainingTotalRequestTime indicates how long the desiredTotalRequestTime is left. If remainingTotalRequestTime is 0 (zero), the request has been timed out. If remainingTotalRequestTime is a negative value (-1), it would mean that each file request will be tried at least once.
o If input parameter desiredTotalRequestTime is 0 (zero), each file request will be tried at least once.� Negative value is not valid
o Output parameter remainingDeferredStartTime indicates how long the deferredStartTime is left, if supported. Negative value is not valid.
o Output parameter remainingTotalRequestTime indicates how long the desiredTotalRequestTime is left. If remainingTotalRequestTime is 0 (zero), the request has been timed out. If remainingTotalRequestTime is a negative value (-1), it would mean that each file request will be tried at least once.
o comments added: TURLs will not be valid any more after the desiredPinLifetime is over if srmPutDone or srmAbortRequest is not submitted on the SURL before expiration.
o Upon srmPrepareToPut, SURL entry is inserted to the name space, and any methods that access the SURL such as srmLs, srmBringOnline and srmPrepareToGet must return SRM_FILE_BUSY at the file level. If another srmPrepareToPut or srmCopy were requested on the same SURL, SRM_FILE_BUSY must be returned if the SURL can be overwritten, otherwise SRM_DUPLICATION_ERROR must be returned at the file level.
o Input parameter desiredFileLifetime is the lifetime of the SURL when the file is put into the storage system. It does not refer to the lifetime (expiration time) of the TURL. Lifetime on SURL starts when successrul srmPutDone is executed.
o If input parameter desiredTotalRequestTime is 0 (zero), each file request will be tried at least once.� Negative value is invalid.
o Output parameter remainingTotalRequestTime indicates how long the desiredTotalRequestTime is left. If remainingTotalRequestTime is 0 (zero), the request has been timed out. If remainingTotalRequestTime is a negative value (-1), it would mean that each file request will be tried at least once.
o comments added: TURLs will not be valid any more after the pin lifetime is over if srmPutDone or srmAbortRequest is not submitted on the SURL before expiration.
o Lifetime on SURL starts when successrul srmPutDone is executed
o SRM_ABORTED is returned at the request level at the successful abort of the request.
o SRM_NO_USER_SPACE, SRM_NO_FREE_SPACE and SRM_FILE_BUSY are added at the file level status.
o srmRm may remove SURLs even if the statuses of the SURLs are SRM_FILE_BUSY. In this case, the status for srmPrepareToPut request must return SRM_INVALID_PATH upon status request or srmPutDone.
o srmRm may remove SURLs even if the statuses of the SURLs are SRM_FILE_BUSY. In this case, SRM_INVALID_PATH must be returned upon srmPutDone request.
o If any additional srmPutDone is requested on the same SURL, SRM_DUPLICATION_ERROR must be returned at the file level.
o Upon srmCopy, SURL entry is inserted to the target name space, and any methods that access the target SURL such as srmLs, srmBringOnline and srmPrepareToGet must return SRM_FILE_BUSY at the file level. If another srmPrepareToPut or srmCopy were requested on the same target SURL, SRM_FILE_BUSY must be returned if the target SURL can be overwritten, otherwise SRM_DUPLICATION_ERROR must be returned at the file level.
o If input parameter desiredTotalRequestTime is 0 (zero), each file request will be tried at least once.� Negative value is invalid.
o Output parameter remainingTotalRequestTime indicates how long the desiredTotalRequestTime is left. If remainingTotalRequestTime is 0 (zero), the request has been timed out. If remainingTotalRequestTime is a negative value (-1), it would mean that each file request will be tried at least once.
o srmRm may remove SURLs even if the statuses of the SURLs are SRM_FILE_BUSY. In this case, the status for srmCopy request must return SRM_INVALID_PATH upon status request.
o Includes a statement about the lifetime of the request token.
o Statement that userRequest[Space]Description may be null, and it is case-sensitive when provided. SRM server is expected to keep it as client provides. It can be reused by the client. It can be used in the srmGetRequest[Space]Tokens function to get back the system assigned request or space tokens.�
o srmPrepareToGet, srmStatusOfGetRequest, srmBringOnline, srmStatusOfBringOnlineRequest, srmPrepareToPut, srmStatusOfPutRequest, srmCopy, srmStatusOfCopyRequest
o added comments
o SRM_NO_USER_SPACE and SRM_NO_FREE_SPACE are added at the file level status.
o TGetRequestFileStatus, TBringOnlineRequestFileStatus, TPutRequestFileStatus, TCopyRequestFileStatus
o Negative value, -1, for unknown.
o TTransferParameters may be provided optionally in the methods such as srmPrepareToGet, srmBringOnline, srmPrepareToPut and srmReserveSpace. Optional input parameters in TTransferParameters may collide with the characteristics of the space specified. In this case, TTransferParameters as an input parameter must be ignored.
o lifetimeAssigned is the total lifetime that is assigned on the SURL. It includes all SURL lifetime extensions if extended.
o lifetimeLeft is the remaining lifetime that is left on the SURL.
o lifetimeAssigned is the total lifetime that is assigned to the space. It includes all space lifetime extensions if extended.
o lifetimeLeft is the remaining lifetime that is left on the space.