Hiding plugin changes from users

Deadline
1

I have been working on some updates to Deadline’s Shotgun plugins. I copied the plugins into custom/events and got to work. I was happy to see my changes show up in the Project Management tab.

However, I do have a concern. People are using the farm while I am working. How do I hide my changes from them?

2

I have found that spinning up another server of deadline and moving a machine accroos to it is the best way to do dev like this.
The reason i like this workflow the most, is that as a coder its really easy to break the entire farm :cry:

we have a few monitor scripts and documented workflow for moving a job from one farm to another. (and trying to make it more seamless)
but pretty much we wrap the job archive and job import commands in the dl monitor to make it more seemless.

my 2 cents.

3

Ugh. I see what you mean.

Maybe the other option is to get Deadline to see the custom plugins as another choice? Users can pick ‘Shotgun’ while I work on ‘Custom Shotgun’. This would keep users from using the plugin I am developing. However, it will not protect their farm if I crash it by mistake.

4

Yup, that’s what Deadline developers do; run a local db/repo for super easy dev testing (laptop/workstation/whatever works for you), maybe also a local network db/repo for certain kinds of tests and then send it to our main farm which we call AWS for short. :laughing:

5

It is pretty standard development practice to have a test or staging area, so it’s a good habit to get into:
en.wikipedia.org/wiki/Deployment_environment

A/B testing where some users see option A and others see option B is not usually used for development and instead proving a design is worth using.

6

Okay, our engineer set up a nice development environment for me. I started to track changes in the development repository with Git. I noticed Git is tracking a LOT of files. Is there anything I can ignore?

7

Well, I’d version control just the ‘custom’ folder which by default is a bunch of empty folders (which Git won’t even be willing to commit).

If you’re versioning the whole Repo, definitely ignore the backup, jobs, pythonsync, jobsArchived, reports, and bin folders. The ‘settings’ folder isn’t really developer focused, so I’d gitignore that one after the first commit so you’re not rebasing some old config file by accident.

8

One of our developers noticed the “Custom Plugin Directory” field:

see:
docs.thinkboxsoftware.com/produ … enviro.png

Can we use this to point to a different custom directory? If so, is there a way to set this as an an environment variable, so we can script it?

Or do you recommend a separate repo?

Sam.

9

Hmm. Well, we don’t have a variable for it:
docs.thinkboxsoftware.com/produ … naged.html

For development I always recommend a staging area. A dedicated machine that will host a different Repository and Database that some production render nodes can connect to. That’s enforcing (my preferred) workflow, but I think it’s good to have it segregated so mistakes don’t take down the farm. There are ways to switch over the render nodes’ Repository though. Deadline command has a function for it:


ChangeRepository
  Allows you to change the Repository Connection Settings that Deadline uses by
  default. If no arguments are provided, the Change Repository dialog will be
  displayed.
    [Connection Type]        Optional. Specifies the type of connection to
                             use when connecting (either Direct or Proxy). If
                             not specified, the type will be inferred from
                             the connection string.
    [Connection String]      When using Direct connection, this is the path
                             to the root of the Repository. When using a
                             Proxy connection, this is a string of format
                             <HOST>:<PORT>.
    [Client Certificate]     Optional. The path to a client certificate to
                             use when connecting to a Proxy or Database over
                             SSL/TLS.
    [Certificate Password]   Optional. The password to the provided Client
                             Certificate, if required. Only used for Direct
                             connections.
10

Posting here since my question seems to fit into this discussion:
The Custom Plugin Directory control would suggest that one could run an alternate version of a plug-in on the production farm. This would be very useful when unable to replicate a problem on a separate dev system.

We’ve been trying to make it work, but it looks like the slaves are caching the regular script. Is there a standard way to clear that cache, or get the slave to skip it? Thanks!

11

The cache should only take effect when either local caching is explicitly enabled or you’re using a Proxy connection.

I’m thinking you may have encounted a bug though, so is reproducing as easy as defining that new directory and trying to see if the custom scripts copy over to “%localappdata%\Thinkbox\DeadlineX\cache”?

12

(I should note that this is running version 8 - we’re standing up a Deadline 10 setup now, but it’s not ready.)

It does appear that the custom script isn’t coming over. The log says it’s running from the custom directory, but then there’s this line:

INFO: Executing plugin script '/tmp/Thinkbox/Deadline8/slave/rndr025/plugins/59bb2f4a954a8b1ea0e356c2/MayaBatch.py

And when we inspect that file, it’s the old script, not the custom one.

Thanks!

13

Ah, there were a number of different issues in early versions of 8.0. If you want to upgrade, you can download the latest 8.0 from here with an Amazon account:
downloads.thinkboxsoftware.com/

If you don’t have/want an Amazon account, we can still pass the ye olde download links if you e-mail support@thinkboxsoftware.com.