0

tk-nuke: Manually specify shotgun user for renderfarm rendering

Permanently deleted user

July 28, 2015 16:21

None

Follow

Hi!

 

We're trying to render Nuke scripts containing tk-nuke-writenodes on our renderfarm.

 

This fails because our nuke script template has user-specific parts in them (the initials of the artist). However, the user on the renderfarm can't be the one that submits the job, it's just the render-user which started the (Deadline) render slave. So loading the tk-nuke-writenodes app fails because it can't load the Nuke script filename template.

 

Is there any way using sgtk to force the user context to be a certain user? I tried figuring out the user from the nuke script being opened, using the contained artist initals to look up the user in Shotgun and then putting this into the context the tk-nuke engine is started with (in Nuke's init.py). However, as soon as the render Nuke script is opened, sgtk constructs a new context from the filename overwriting the old one and loses the user again (causing the tk-nuke-writenode app to fail -> TankWrite nodes are unknown to Nuke -> render fails).

I guess we could take the initials out of the templates, but we would really like to keep them...

(I'm also looking into having Deadline set the environment of the render job to contain the user login who submitted the job, which might solve the problem in a more general way).

Cheers,

SebastianH

• Facebook
• Twitter
• LinkedIn

3 comments

• 0
  
  Permanently deleted user July 28, 2015 19:07

  Hello!

  One option would be to capture the context on the artist's machine using the sgtk.context.serialize(context_obj) call - this method will serialize a context to a string. You can reach the current context via sgtk.platform.current_engine().context. Then when you start up the toolkit engine on the farm, just pass in that string into the sgtk.context.deserialize(context_str) method which will then recreate that same context. Then use that context to start the render farm session.

  Do you think that could work?

  Thanks!
  Manne

• 0
  
  Permanently deleted user July 28, 2015 19:07

  Hi!

  Thanks for the suggestion, that's really usefull to know! I don't think it would work in this case though (at least as far as I understand what's happening with sgtk in Nuke) (see below).

  I did get it to work by just tweaking the Deadline Nuke submitter to include environmentkeys for 'USERNAME' based on the environment in which the job is submitted. This gets the Deadline render slave to pretend to sgtk that it's not actually the render user but the artist running Nuke. I think this is a good solution, certainly solves the problem we had, so it's all good.

  Why I think recreating the context fails is, because I think the following will happen in Nuke:

  1. I recreate the sgtk context in Nuke (in init.py, where we also have code that loads the tk-nuke engine)

  2. Nuke loads the script

  3. sgtk creates a new context from the new filename and the environment, and fails to find a shotgun user

  4. tk-nuke-writenode doesn't load

  5. TankWrite nodes are unknown to Nuke

  6. At this point I could maybe run a script which recreates the context, but it's too late to fix the opened Nuke script

   

• 0
  
  Permanently deleted user July 28, 2015 19:07

  Very interesting! Thanks for the feedback Sebastian! Glad you found a workaround. 

  The auto-switching that is going on here is also something that has been on our todo-list for a while, we are hoping to get that addressed at the same time as we are revisiting some of the concepts around the context handling in general. Thanks for this feedback - it will help us build a better and more useful v2!