Bug 2680 - Can't change source url for gram job staged files
: Can't change source url for gram job staged files
Status: RESOLVED WONTFIX
: GRAM
wsrf managed execution job service
: 3.9.5
: All All
: P3 enhancement
: 4.4
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2005-02-02 14:32 by
Modified: 2012-09-05 11:42 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2005-02-02 14:32:18
To my knowledge, once a ws-gram job is submitted, it is not possible to change
the source URL for any stage files that are part of that job. This makes it
painful to use a source url that includes a dynamic port. If the client gridftp
server crashes and restarts on a different port, all submitted jobs must be
removed and resubmitted, losing any work they've accomplished. This is likely to
be the way that Condor-G will operate in the future (standing up its own gridftp
server).

We would like the ability for a client to change the source URL of staged files
after the corresponding job resource has been created. We feel this is important
functionality for good fault-recovery.
------- Comment #1 From 2005-02-02 14:39:03 -------
This is a loss of functionality versus pre-web services GRAM, which does allow
the updating of source URLs for staged files.
------- Comment #2 From 2005-02-02 16:08:19 -------
I don't see this happening in 4.0.  We'll have to talk about what makes sense
to do for 4.2

For 4.0, here are a couple options:

1. Ensure that the URL won't change.  Use a well known port for the client side
GridFTP server

2. Stage the files by hand (not gram).  Use the cleanup hold feature to stop
the MEJS from cleaning up 
the jobs files.  Stage the files by hand through the GridFTP server.  Then
release the job to complete the 
cleanup.
------- Comment #3 From 2005-11-02 17:43:49 -------
We've talked about publishing the FS mapping XML document as an RP.  Perhaps we
should do that and say, "if you want finer control over staging, then you need
to use RFT or GridFTP directly."  After all, at best this creates a race
condition between when GRAM submits transfer requests to RFT and the server URL
update.  So it may not even work and you'll have to re-submit the job anyway.
------- Comment #4 From 2005-11-02 20:01:52 -------
Would it be feasible to add support in RFT for changing the URLs for an
existing transfer resource? The 
new URLs would be used the next time a transfer is attempted.
------- Comment #5 From 2006-10-02 12:20:44 -------
Would an acceptable solution to this be to simply provide a gsiftp URL list RP
for selected files? This wouldn't give you the reliability of RFT, but would
allow you to simply pull the files and not worry about a client-side GridFTP
server.
------- Comment #6 From 2006-10-02 13:00:02 -------
Subject: Re:  Can't change source url for gram job staged files

We talked about adding this capability to RFT where we provide an 
operation to "modify" a request. There was not enough interest to 
convince development time.

bugzilla-daemon@mcs.anl.gov wrote:
> http://bugzilla.globus.org/bugzilla/show_bug.cgi?id=2680
> 
> 
> 
> 
> 
> ------- Comment #5 from lane@mcs.anl.gov  2006-10-02 12:20 -------
> Would an acceptable solution to this be to simply provide a gsiftp URL list RP
> for selected files? This wouldn't give you the reliability of RFT, but would
> allow you to simply pull the files and not worry about a client-side GridFTP
> server.
> 
> 
> 
> 
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.
> 
------- Comment #7 From 2006-10-02 14:52:59 -------
Providing a list of gsiftp URLs for the client to transfer is a possible
solution. We'll have to investigate how much work it'd be to add support for
this in Condor-G.
------- Comment #8 From 2007-09-19 11:37:52 -------
Reassigning to current GRAM developer to close/fix as appropriate.
------- Comment #9 From 2012-09-05 11:42:26 -------
Doing some bugzilla cleanup...  Resolving old GRAM3 and GRAM4 issues that are
no longer relevant since we've moved on to GRAM5.  Also, we're now tracking
issue in jira.  Any new issues should be added here:

http://jira.globus.org/secure/VersionBoard.jspa?selectedProjectId=10363