FTS3Job

FTS3Job module containing only the FTS3Job class

class DIRAC.DataManagementSystem.Client.FTS3Job.FTS3Job

Bases: JSerializable

Abstract class to represent a job to be executed by FTS. It belongs to an FTS3Operation

ALL_STATES = ['Submitted', 'Ready', 'Active', 'Finished', 'Canceled', 'Failed', 'Finisheddirty', 'Staging', 'Archiving']
FINAL_STATES = ['Canceled', 'Failed', 'Finished', 'Finisheddirty']
INIT_STATE = 'Submitted'
NON_FINAL_STATES = ['Staging', 'Submitted', 'Ready', 'Archiving', 'Active']
__init__()
assignment
cancel(context)

Cancel the job on the FTS server. Note that it will cancel all the files. See https://fts3-docs.web.cern.ch/fts3-docs/fts-rest/docs/api.html#delete-jobsjobidlist for behavior details

completeness
error
ftsGUID
ftsServer
static generateContext(ftsServer, ucert, fts_access_token=None, lifetime=25200)

This method generates an fts3 context

Only a certificate or an fts token can be given

Parameters:

  • ftsServer – address of the fts3 server

  • ucert – the path to the certificate to be used

  • fts_access_token – token to access FTS

  • lifetime – duration (in sec) of the delegation to the FTS3 server (default is 7h, like FTS3 default)

Returns:

an fts3 context

jobID
lastMonitor
lastUpdate
monitor(context=None, ftsServer=None, ucert=None)

Queries the fts server to monitor the job. The internal state of the object is updated depending on the monitoring result.

In case the job is not found on the server, the status is set to ‘Failed’

Within a job, only the transfers having a fileID metadata are considered. This is to allow for multihop jobs doing a staging

This method assumes that the attribute self.ftsGUID is set

Parameters:

  • context – fts3 context. If not given, it is created (see ftsServer & ucert param)

  • ftsServer – the address of the fts server to submit to. Used only if context is not given. if not given either, use the ftsServer object attribute

  • ucert – path to the user certificate/proxy. Might be infered by the fts cli (see its doc)

Returns:

{FileID: { status, error } }

Possible error numbers

  • errno.ESRCH: If the job does not exist on the server

  • errno.EDEADLK: In case the job and file status are inconsistent (see comments inside the code)

operationID
status
submit(context=None, ftsServer=None, ucert=None, pinTime=36000, protocols=None, fts_access_token=None)

submit the job to the FTS server

Some attributes are expected to be defined for the submission to work:

  • type (set by FTS3Operation)

  • sourceSE (only for Transfer jobs)

  • targetSE

  • activity (optional)

  • priority (optional)

  • username

  • userGroup

  • filesToSubmit

  • operationID (optional, used as metadata for the job)

We also expect the FTSFiles have an ID defined, as it is given as transfer metadata

Parameters:

  • pinTime – Time the file should be pinned on disk (used for transfers and staging) Used only if he source SE is a tape storage

  • context – fts3 context. If not given, it is created (see ftsServer & ucert param)

  • ftsServer – the address of the fts server to submit to. Used only if context is not given. if not given either, use the ftsServer object attribute

  • ucert – path to the user certificate/proxy. Might be inferred by the fts cli (see its doc)

  • protocols – list of protocols from which we should choose the protocol to use

  • fts_access_token – token to be used to talk to FTS and to be passed when creating a context

Returns:

S_OK([FTSFiles ids of files submitted])

submitTime
userGroup
username