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

Support host mounts in containers #233

Closed
kegsay opened this issue Nov 19, 2021 · 2 comments · Fixed by #312
Closed

Support host mounts in containers #233

kegsay opened this issue Nov 19, 2021 · 2 comments · Fixed by #312
Assignees

Comments

@kegsay
Copy link
Member

kegsay commented Nov 19, 2021

Developers often want to run new tests against a local version of their HS. This is cumbersome at present as you have to rebuild a docker image before you can run the test. Instead, we can expose directory on the container which will be volume mounted from a new env var e.g:

COMPLEMENT_MOUNT=/Users/me/my/local/dendrite
COMPLEMENT_BASE_IMAGE=dendrite-which-reads-mounted-dir:latest
go test ./...
  • Should we just expose the source location or also the destination location e.g COMPLEMENT_MOUNT=/Users/me/my/local/dendrite:/data
  • We should standardise the mounted directories (as /ca is done for COMPLEMENT_CA=1) as we will inevitably expand this in the future (e.g appservices need registration YAML files in the container)

We can either be prescriptive and say that we map to a static directory layout:

/complement
    |__ /appservice
    |__ /ca
    |__ /mount

or we can make this configurable e.g:

COMPLEMENT_MOUNT=/Users/me/my/local/dendrite:/mnt
COMPLEMENT_CA=/Users/me/my/ca:/certs
COMPLEMENT_AS=/Users/me/my/appservices:/as

This feels wrong though as it then ties env vars to a specific docker image which isn't what we're trying to do here (we want them to be interchangeable), so let's be prescriptive.

@ShadowJonathan
Copy link
Contributor

ShadowJonathan commented Dec 1, 2021

I think these mounts should be read-only, considering that Complement isn't supposed to do more than just read their code.

(I can think of write-specific side-effects in programming languages like python, which add write bytecode alongside the source code, or create directories like __pycache__, best to isolate that)

Any write-specific issues and behaviour can be fixed by layering a copy-on-write layer on top of it (though i can't remember exactly how or if thats possible with docker)


Regarding mapping; i think that complement should document well-known locations (/mnt, /certs, and /as in that example) within its container, and then have the developer submit a ;-seperated mount list to the runner.

@kegsay
Copy link
Member Author

kegsay commented Feb 10, 2022

Thought about this a bit more and we need to allow arbitrary mounts so devs are free to mount things like GOPATH, pycache, etc to speed up edit-compile-run cycles... it also needs to be repeatable and not pollute the mounted volumes else we risk contaminating blueprints.

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

Successfully merging a pull request may close this issue.

2 participants