Conductor can be installed in a variety of ways to meet the appropriate setup for any studio or user.
Keys to success:
- Consistent file pathing throughout the studio and across multiple OSes. (e.g. c:\cat.jpg vs /mnt/share/cat.jpg.
- Running uploader/downloader daemons on a dedicated machine or machines, you can move these resource grabbing lifts away from the artist's machines.
- The uploader and downloader's view of the file system must match that of the user who submitted the job. (e.g. artist submits a job with the output directory "/users/artist1/projects/GWTW/images", the download machine must contain or be able to create that location).
Here are the guiding principles documented below:
- There are multiple users with all dependencies and rendered images saved to their local machine.
- There are multiple users accessing and saving to a central server.
- There are multiple users sharing and accessing dependencies from one server and writing rendered images to another server.
- There are multiple users across multiple locations on a shared system. (e.g. Vancouver vs Los Angeles)?
There multiple users with all dependencies and rendered images saved to their local machine.
- Install the Conductor tools to each of the artist's machines.
- Locate their unique Conductor token locally or in a private folder on the network.
- Locate the shared single config.yml on a shared folder. We recommend that the config.yml is write protected to prevent accidental overwrite or corruption. See more about the config.yml here.
- Point all environment variables to point to a shared single config.yml file.
There are multiple users accessing and saving to a central server.
- Follow the steps for principle 1 above.
- Install/extract Conductor client to a location on a shared file system.
- Use a daemon token for the uploader/downloader daemons. By installing the uploader/downloader daemons on a dedicated machine or a machines, you can move these lifts away from the artist's machines.
In the above recommended configuration, each artist will still be able to be identified by name and still use a single configuration file. That way, studio configurations such as download locations will only need to be made once, while individual artist identities will be maintained.
There are multiple users sharing and accessing dependencies from one server and writing rendered images to another server.
- Follow the steps in Principle 2 A & B.
- On the machine used to store project dependencies, install the uploader daemon.
- For the machine used to receive the resulting rendered images, install and run the downloader daemon.
If the studio has multiple locations, i.e on different file systems (LA vs Vancouver vs London, etc), follow the same principles above, per each location. This means that every location has its own
config.yml file (whose contents include a distinct location field specified, e.g. location: vancouver)
- Follow steps in Principle 2 or 3 above using the principles that best fit your situation.
- Uploading/Downloading across your WAN is dependent on its performance. For slower WAN's, it is recommended to up/download locally and copy to the central location. If the WAN can support necessary speeds, using UNC pathing directly to the central depository is an option.