Understanding Mount option in install

Regarding the mount option in install i.e.

    --mount=MOUNT            One or several mount overrides in the following format: <mount-name>:<path>, e.g. data:/var/lib/data.

Is it’s use to bind a directory on the local node to the container where the install script is run?

Based on customer data, I generate helm chart values and configmaps which I would like to be accessible to my install script which is called within the gravity install process.

I have the following command:

sudo ./gravity install --advertise-addr= --token=pg123456 --cloud-provider=generic --mount=/var/lib/data:/var/lib/data

Where I have stored my config data in /var/lib/data on the local machine where the gravity install script is being run.

Is that the correct approach?

But the <mount-name> makes the above assumption weak
If it is docker volumes and not bind mount, then I need to create a volume using docker? But my understanding is that docker should not be installed on the nodes where we want to install the cluster, then I can’t create the volume?

--mount mounts a directory from host inside the gravity container which is the runtime environment for Kubernetes - it is similar to docker run --volume=.... Other containers (i.e comprising kubernetes Pods) are executed in the context of the gravity container. So, with the configuration like this:

gravity install --mount=/path/on/host:/path/inside/gravity/container

/path/inside/gravity/container will then be the path available inside the gravity container and which can then be used as a volume in the kubernetes resource configuration.