Turning a centralized config into a distributed config for some users

Now that we have a bunch of users working remotely over VPN I need to turn my centralized config into a distributed config.

Our config has a shared core and I’ve modified core and most engines and apps.

Are there any built in tank commands to quickly copy everything I need to zip up somewhere so it will work self contained?


There aren’t, unfortunately, any tank commands for this.
The easiest thing is to do is to copy the bundle cache over to the config you are uploading:

In my image, I have

  1. Copied the config folder out of my project configuration location to a temporary location
  2. Deleted the install_location.yml and the pipeline_configuration.yml from the copied config.
  3. Copied the install folder over from my shared core > install folder into the root of my copied config folder and renamed it bundle_cache.
    Note at this point ideally you only want it to contain the bundles you have modified to help keep the size down, and only keep the version of the bundle that the config is using. To quickly filter them down you could tank localize on your project, delete the contents of the app_store folder from your projects install folder, and then run tank cache_apps so that it only contains the versions your config is using. If you have a customized tk-core then you should also copy it into the bundle_cache folder following the same format/structure


Ideally, you would switch to uploading your modified bundles as individual items to Shotgun (against a custom entity) and then using the Shotgun descriptor in your config as the location. That way your users wouldn’t need to download everything again each time you updated the config.


There’s also this resource in our documentation that covers the basics of a distributed configuration.


How often does it redownload the config after I make an update?
If I change a maya hook will it update the next time they launch maya or do they need to exit and reenter the project to get it to update?


There was a thread on the topic of updating the config, which you might find contains useful information here:

But in short, by default they would need to exit and reenter the project for it to recache.

It will only download the config if it doesn’t already have it locally. It caches it by the id of the uploaded file, so when you upload a new config the id will be different and if it doesn’t have that id locally it will pull it.

1 Like


I just want to clarify something. Depending on which config you based your own, you will get a different behaviour. tk-config-basic based configs will get the latest version of a config every single time you launch a DCC. tk-config-default2 based configs on the other hand will get the latest version of a config when you launch a project from Shotgun Desktop and not every single time you launch a DCC.

It all boils down to a pretty cryptic setting in an engine’s config named launch_builtin_plugins (see here in the basic config). When this setting is set to [basic] on a engine for a given environment (project in this case), the Toolkit will use our newer startup logic which will download the latest version of a pipeline configuration from Shotgun instead of using the one that was downloaded by the Shotgun Desktop.

It’s a bit of oversight on our part, this setting should have been present in the default2 config and we’re considering making this behaviour the default one regardless of this setting’s value, but doing so might mean we would have deprecate older versions of tk-core which we always careful about doing so we want to think this through first.


1 Like

I got a batch script written using this info and it looks like it should work.
I’m hitting an error with tk-multi-launchapp though. I’ve sent in a support ticket with the specifics of the error I’m seeing.


I got it working. I was missing a couple of bits with core.

core needs to be copied to bundle_cache/app_store/tk-core/v0.19.3/ or whatever version
core_api.yml in the config need to be using the correct version of core.
Centralized configs seem to work no matter what version is set in that file so I hadn’t updated it before.


It depends on how you have core set up, but yes you will need to copy it over to the bundle cache folder. In my example I had my core_api.yml using a git descriptor, so mine needed to go in .../bundle_cache/gitbranch/tk-core.git/{commit id}. That said what you’ve done is perfectly fine as well.

Centralized configs seem to work no matter what version is set

Yeah, that is the case. When you run tank core on a centralized config, it should update the core_api.yml but if you were using a customized core I can certainly understand why you wouldn’t have changed that yml file.

We’ve made a post today about how to turn a centralized configuration into a distributed one. There’s even a script that automates part of the process.
Hopefully this can help you out.

1 Like