Global Configuration
What is the global ZenML config
This is an older version of the ZenML documentation. To read and view the latest version please visit this up-to-date URL.
The Global Config
The information about the global settings of ZenML on a machine is kept in a folder commonly referred to as the ZenML Global Config Directory or the ZenML Config Path. The location of this folder depends on the operating system type and the current system user, but is usually located in the following locations:
Linux:
~/.config/zenml
Mac:
~/Library/Application Support/ZenML
Windows:
C:\Users\%USERNAME%\AppData\Local\ZenML
The default location may be overridden by setting the ZENML_CONFIG_PATH
environment variable to a custom value. The current location of the Global Config Directory used on a system can be retrieved by running the following command:
Manually altering or deleting the files and folders stored under the ZenML Global Config Directory is not recommended, as this can break the internal consistency of the ZenML configuration. As an alternative, ZenML provides CLI commands that can be used to manage the information stored there:
zenml analytics
- manage the analytics settingszenml clean
- to be used only in case of emergency, to bring the ZenML configuration back to its default factory statezenml downgrade
- downgrade the ZenML version in the global configuration to match the version of the ZenML package installed in the current environment. Read more about this in the ZenML Version Mismatch section.
The first time that ZenML is run on a machine, it creates the Global Config Directory and initializes the default configuration in it, along with a default Stack:
The following is an example of the layout of the Global Config Directory immediately after initialization:
As shown above, the Global Config Directory stores the following information:
The
global.yaml
file stores the global configuration settings: the unique ZenML user ID, the active database configuration, the analytics related options the active Stack and active Workspace. This is an example of theglobal.yaml
file contents immediately after initialization:The
local_stores
directory is where some "local" flavors of Stack Components, such as thelocal
Artifact Store, or a local MLFlow Experiment Tracker, persists data locally. Every local Stack Component will have its own subdirectory here named after the Stack Component's unique UUID. One notable example is thelocal
Artifact Store flavor that, when part of the active Stack, stores all the artifacts generated by Pipeline runs in the designated local directory.The
zenml.db
file is the default SQLite database where ZenML stores all information about the Stacks, Stack Components, custom Stack Component flavors etc.
In addition to the above, you may also find the following files and folders under the Global Config Directory, depending on what you do with ZenML:
zenml_examples
- used as a local cache by thezenml example
command, where the pulled ZenML examples are stored.kubeflow
- this is where the Kubeflow orchestrators that are part of a Stack store some of their configuration and logs.
Accessing the global configuration in Python
You can access the global ZenML configuration from within Python using the zenml.config.global_config.GlobalConfiguration
class:
This can be used to manage your global settings from within Python.
To explore all possible operations that can be performed via the GlobalConfiguration
, please consult the API docs sections on GlobalConfiguration.
ZenML Version Mismatch - Downgrading the Global Config
If you've recently downgraded your ZenML version to an earlier release or installed a newer version on a different environment on the same machine, you might encounter an error message when running ZenML that says:
We generally recommend using the latest ZenML version. However, there might be cases where you need to match the global configuration version with the version of ZenML installed in the current environment. To do this, run the following command:
Note that downgrading the ZenML version may cause unexpected behavior, such as model schema validation failures or even data loss. In such cases, you may need to purge the local database and re-initialize the global configuration to bring it back to its default factory state. To do this, run the following command:
Last updated