You can change the default agents configuration by mounting a config file into /opt/datalore/configs/agents-config.yaml inside the Datalore container. This config has the following format:
<name-of-agents-network> is datalore-agents-network, and
<host-of-datalore-server is datalore.
Each instance definition has the following fields:
Specifies the unique id for the instance.
Specifies whether the instance is default. Make sure exactly one instance has this parameter set to
Specifies the instance name shown in the UI.
URI of the agent docker image, changed only to specify a custom agent image
Specifies the local storages mounted to the agent. Find more details in the chapter below.
Specifies when the image will be pulled. Acceptable values are: NEVER, ALWAYS, IF_ABSENT (default).
Specifies how much of the available CPU resources a container can use. For example, if the host machine has two CPUs and you set
Specifies the maximum amount of memory the container can use.
env: - <env1-definition> - <env2-definition> ... - <envN-definition>
Defines environment variables on the agent. Each
env: - name: DATALORE_SKIP_WARMUP value: true - name: DATALORE_MAX_BLOB_SIZE value: 10_000_000
Specifies the number of pre-warmed (pooled) agents. This is the minimum number of agents Datalore will keep started and yet unassigned to any computation. When a notebook is opened, Datalore assigns one of the pooled agents to that notebook and starts another agent to refill the pool. It might be useful to set
Specifies the short instance name.
Specifies the number of CPUs to display.
Specifies the agent RAM description.
Specifies the number of GPUs to display.
Specifies the GPU memory description.
features: - "1 vCPU" - "16 GB RAM" - "1 NVIDIA GPU"
Specifies specific properties of this agent to display in the UI.
Only properties containing the "RAM", "CPU", or "GPU" substrings will be displayed in the agent selection window.
Configure local storages for agents
You can mount a local server storage to your Datalore agents by using the volumes field for the respective instance definition. See the example below:
volume field contains an array of strings with the following format:
host-src:container-dest[:options]to bind-mount a host path into the container. Make sure both
container-destare an absolute path.
volume-name:container-dest[:options]to bind-mount a volume managed by a volume driver into the container. Make sure
container-destis an absolute path.
options is an optional, comma-delimited list of the following:
nocopydisables automatic copying of data from the container path to the volume. The
nocopyflag only applies to named volumes.
[ro|rw]mounts a volume read-only or read-write respectively. If omitted or set to
rw, volumes are mounted read-write.
[z|Z]applies SELinux labels to allow or deny multiple containers to read and write to the same volume.
z: a shared content label is applied to the content. This label indicates that multiple containers can share the volume content, for both reading and writing.
Z: a private unshared label is applied to the content. This label indicates that only the current container can use a private volume. Labeling systems such as SELinux require proper labels to be placed on volume content that is mounted into a container. Without a label, the security system can prevent a container's processes from using the content. By default, the labels set by the host operating system are not modified.
[[r]shared|[r]slave|[r]private]specifies mount propagation behavior. This only applies to bind-mounted volumes, not internal volumes or named volumes. Mount propagation requires the source mount point (the location where the source directory is mounted in the host operating system) to have the correct propagation properties. For shared volumes, the source mount point must be set to
shared. For slave volumes, the mount must be set to either