- 6, I believe - I’ve asked our Systems team to install Beta 7
- I’m on OS X but we also have Windows in our shop (both platforms on the farm)
- See below:
In our Nuke scripts we use python code to point to both input and output directories. This works fine in Deadline but in Draft I’m getting the following error:
=======================================================
Log Message
Checking job for Draft settings…
Found Draft Template: ‘/pfcluster/PROJECTS/_Pipeline/draft/python/4K_createMovie.py’
An error occurred in the “OnJobFinished” function in events plugin ‘Draft’: An error occurred in function “OnJobFinished” the event plugin script file “/Volumes/DeadlineRepository/events/Draft/Draft.py”: Access to the path “/pfcluster/PROJECTS/[value root.show]” is denied. (Deadline.Events.DeadlineEventPluginException)
at Deadline.Events.DeadlineEventPlugin.HandlePythonError (System.String message, System.Exception e) [0x00000] in :0
at Deadline.Events.DeadlineEventPlugin.OnJobFinished (Deadline.Jobs.Job job, System.String[] auxiliaryFilenames) [0x00000] in :0
at Deadline.Events.DeadlineEventManager.OnJobFinished (Deadline.Jobs.Job job, System.String[] auxiliaryFilenames, Deadline.Controllers.DeadlineController deadlineController) [0x00000] in :0
=======================================================
Log Details
Log Date/Time = Mar 19/12 14:36:38
Frames = (no task)
Slave Machine = Farm17
Slave Version = v5.1.0.46398 R
Plugin Name = Draft
Is there a way around this? I’ve just started testing the Resizable_Demo_Template2.py and this was as far as I got. I also tried submitting a Nuke script with hard paths and that errored out due to license issues which we’re working through now. The point is, though, that the python in the Nuke paths isn’t properly being evaluated when passed to Draft, and I’m hoping we can get this working.
Thanks
Bill
323-428-0913
Hi Bill,
From the looks of it, you’re using the Draft Event Plugin to get the Draft jobs on the farm, which actually pulls the output file directly from the Deadline job. It does that by combining the OutputDirectories and OutputFileNames properties of the job (there could be multiple), so it should match whatever’s being listed in the Monitor for the output location.
You mentioned that you’re using python code to point to the input/output directories. At what point, and where, do you do that? Do you know where the ‘[value root.show]’ part of the path could be coming from? It would probably be of great help to me if you could post the code (or at least a snippet of it) that points to the input/output files, so that I can try and reproduce this on my end.
It would probably also be useful to me if you could upload a copy of the job file for one of the Nuke jobs in question. You can find it by right-clicking the job in the Monitor, and selecting “Explore Repository Directory”. That should bring up a finder/explorer window in the correct folder; the file you’ll want to attach will be named something like “999_050_999_68dc47c8.job”.
Once you get back to me with that stuff, hopefully I can figure it out quick and we can knock this one out 
Cheers,
Hi Jon
I’ve attached two Nuke scripts, one with hard coded paths and the other with dynamic paths (’[value root.show]’) that are in the output path of the Write nodes. It seems like what’s happening is that Deadline takes this line in without evaluating it’s knob values, and Draft is using that line to try to bring frames in instead of the actual names of the frames output by Deadline.
I also added the .job file as requested. Hope this helps.
Bill
00f_050_000_7284bdda.job.zip (1.36 KB)
Hey Bill,
I’m only seeing a Job file attached to your post, which also seems to be for the wrong job (it’s a Maya job). But if it’s just a matter of evaluation a knob value inside the Write node’s value, I should be able to come up with a test case to replicate this on my end.
I’ll let you know when I make progress, or if I end up needing your sample Nuke scripts after all
Cheers,
Hey Bill,
I’ve attached an updated Nuke submission script that should fix the problem. It will evaluate any variable strings in Write nodes before passing them on to Deadline (and onto Draft after that).
You should just need to extract the attached script into the ‘submission/Nuke’ folder inside your repository, replacing the old script (you might want to back it up first, just in case). Note that this will only fix newly submitted jobs, and won’t affect jobs already submitted to the farm in any way.
Let me know if this fixes it!
Cheers,
I’m getting a really strange problem now. When I run the variable path script with the Nuke submit script you’ve supplied, I get an error about a stale NFS file handle:
0: STDOUT: Traceback (most recent call last):
0: STDOUT: File “/Local/Farm11/jobsData/4096x3112_1_createMovie.py”, line 30, in
0: STDOUT: inFrame = Image.ReadFromFile(inFile)
0: STDOUT: RuntimeError: Cannot read image file “/pfcluster/PROJECTS/Systems_Test/DESIGN/NUKE/REN/Systems_Test/ProxyTest/SYS_ProxyTest_comp_XXX_v01_bg/4096x3112/SYS_ProxyTest_comp_XXX_v01_bg.0001.exr”. Stale NFS file handle.
0: INFO: Process exit code: 1
When I run the hard path script with your new Nuke submit script, it works fine. Strange that it would have to do with the filesystem but I can’t think of what else might be causing it. Any ideas?
Has this happened multiple times? Does it happen every time you submit with the new script (with the variable names)? If so, could you upload the full slave logs for it failing on the ‘variable’ path, and a success with the hardcoded path (for the same image sequence, and preferably the same slave)?
From what I’ve gathered researching that error message (“Stale NFS file handle”), it seems unlikely that Deadline would be causing this, so I’d be surprised if this wasn’t a one-off thing. This error is supposedly commonly caused by the NFS Server restarting, network issues, or the server-side file changing without the timestamp being updated. Did you guys experience any kind of network-related issues around the time you were testing this?
Anyways, hopefully the slave logs will shine more light on this.
Cheers,
The Stale NFS file handle error is gone. Must’ve been a gremlin that got washed out.
The ‘variable’ path is definitely working too. Thanks for that!