Question about VOSpace and cold storage

[Zorba, Sonia]

Hi Brian,

Our implementations of VOSpace at CADC don't yet implement pullToVoSpace.
> So, I can't speak from experience, but I believe it is absolutely the
> correct vospace 'direction' to use to implement your tape import
> requirement.
>

Thank you for confirming that we are interpreting correctly.


> Regarding the 'phase' in the asynchronous pullFromVoSpace operation:  the
> specification is probably not clear enough about how the jobs phases
> reflect transfer negotiation and the resulting byte transfer.  With our
> 'vault' implementation (the one based on distributed object storage) we
> took a different approach:  our jobs are in the EXECUTING phase during byte
> transfer, and then are set to COMPLETE or ERROR when that's done.  However,
> this is problematic as the service handling the byte transfer must make a
> callback to vospace to set the final phase.  This introduced an undesirable
> coupling between vospace and the service handling the byte transfer.  Also,
> since that callback can fail, we need to monitor and correct those failures
> in an out-of-band process.  If we get a chance to refactor this we will
> probably choose to set the phase to COMPLETE or ERROR immediately after
> transfer negotiation is complete, and consider the ensuing byte transfer an
> operation that is outside the scope of the VOSpace protocol.
>

In the recommendation document, the first pullFromVoSpace example ends with
"On successful file transfer completion the job will be COMPLETED", so it
seems that your implementation is following the recommendation. Do you
think that this behaviour could be redefined in newer versions of the
document?

I'm worried about the coupling between vospace and transfer service too,
but I think that it happens also in another situation: setting the busy
flag of the node to true during the byte transfer for the pushToVoSpace
operation. Is that correct or am I missing something?

Thanks,
Sonia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/grid/attachments/20201215/4726eb70/attachment.html>