Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

find substitute for docker volume mounting #1701

Open
Tracked by #1696
mwartell opened this issue Oct 17, 2022 · 1 comment
Open
Tracked by #1696

find substitute for docker volume mounting #1701

mwartell opened this issue Oct 17, 2022 · 1 comment

Comments

@mwartell
Copy link
Collaborator

mwartell commented Oct 17, 2022

Armory allows many resources to be mounted from a local filesystem into the docker container at the beginning of an armory run. These include

cwd dataset_dir local_git_dir output_dir saved_model_dir tmp_dir

The mechanism allows, for example, making gigabyte datasets available to the container without rebuilding or adding GB to the image size. While this works nicely for a local filesystem which caches the datasets, it is not exportable to
remote container execution in Kubernetes (or similar).

The armory launcher phase is capable of pulling remote resources to the local disk prior to running a container. That means we already have code capable of demand loading datasets, models, etc. onto the local machine.

In some ways, this issue is calling for delayed binding of the remote resources. That is, rather than pull a dataset to the local disk and mount that into a container, direct access from the container to the resource would free Armory from requiring a pre-loaded disk cache.

We'll need to distinguish remote read-only resources (weights, repos) and write-capable remote resources like output_dir.

@ExistentialRecursionist
Copy link
Contributor

ExistentialRecursionist commented Oct 21, 2022

I agree that the current launcher does not implement bind mounts in the most appropriate way, however, kubernetes et. al. do allow for remote bind mounts; be it from a ceph cluster, separate container, etc. Implementing these changes via a compose file(e.g. docker-compose.yml) is more in line with best practices and makes pivoting to a kints cluster a bit simpler; as the yaml for a pod is quite similar(see here for an example armory compose file).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants