-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
task_sandbox
broken for raptor tasks
#2802
Comments
I think it was discussed elsewhere, but a corollary that @andre-merzky may be intending to tackle: 1.1 Explicitly setting the |
@eirrgang : can this be closed after the last iteration? |
I believe so, but I haven't personally checked all cases. Can you confirm that the following have been addressed or won't be addressed?
|
That is not possible in our current approach: the task sandbox is interpreted on the remote resource, and thus it's validity can only be ascertained once the task reaches the agent (and, in this case specifically, the raptor worker). |
Does a non-default value of |
Oh. Excuse me, maybe. I'm not asking for a new feature---just predictability with respect to standard use cases. My impression was that setting task_sandbox was a normally supported use case. If not, then this point is irrelevant (assuming that task_sandbox is never inappropriately user-assignable). However, the current docs allows a sandbox field in the TaskDescription as long as it is relative to the pilot sandbox. |
We may talk a bit cross-purpose I think - or at least I may be missing the point. Let me try to do this stepwise.
The last statement reads like an ipso facto, so I am likely missing something? |
Duh, I should read a bit more carefully. You also wrote:
That was corrected in the docs: the sandbox does not need to be relative to the pilot sandbox anymore, that restriction was lifted a while ago. |
Which part is not possible? The error? If there is some part of the protocol in which a raptor task is less able to perform error checking than a traditional task, then we should document it. If assignment to sandbox for a raptor task (a task with "scheduler" set) behaves the same as for non-raptor tasks, then this item is fine. (I updated the checklist item text in an attempt to clarify) |
Sorry, some quoting went wrong. Let me reply to the changed text:
Yes, the task will move to PS: This holds for all tasks, not only Raptor tasks. |
I believe this is a known problem, but I don't see that it is explicitly tracked and is likely to cause confusion.
task_sandbox
property of a raptor task generated on a client has a constructed path that is never created or used in the execution environment.task:///
URI scheme does not work in staging directives raptor tasks.The text was updated successfully, but these errors were encountered: