Stuck on an issue?
Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Expose to workspace directory from within the host machine
See original GitHub issueIssue Description
Reproduction Steps: This is a blocking issue to mount docker directories from within a workspace.
Like https://github.com/eclipse/che/issues/2771, for Codenvy one may want to trust their users/developers and allow them to build/run docker images from withing a Codenvy workspace (e.g. using the exposed docker socket).
The issue is that volume mounts will not work even if the workspace and docker are on the same machine.
There is a rather simple solution for when docker and the workspace are on the same machine, by at least providing an environment variable with the workspace full path from within the host. For example, from within the workspace it’s /projects but it may expose like $CODENVY_WORKSPACE_HOST_DIR as being /home//codenvy/instance/data/codenvy/fs/35/9a/34/workspacedl17qxo67sbce4a9.
Without this information it’s pretty much impossible (as far as I know) to mount volumes (i.e. files in the workspace so as to refresh instantly). With such an environment variable, one can create symbolic links, or change mount path and if docker runs on the same machine it’d work.
Codenvy version: 5.5.0
OS and version: Linux
Issue Analytics
- State:
- Created 6 years ago
- Comments:10 (9 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
@wernight - I am giving significant thought to this, but it will take some time. Bad luck, but I am heading out on Friday for a 16 day holiday that I have had scheduled for about a year. It’s just something that is important for my wife and I.
But you are correct on the differences between Codenvy and Che. However, we have frequently considered something like NFS or SMB, but we have always avoided it because they turn out to be solid solutions for read-instensive activities, but less than stellar for write-intensive activities. We had an implementation that depended upon Gluster or awhile, but the perf was not up to par becuase of write-requirements. Imagine a scenario where you git clone a repo with 10K small files, the write performance was awful and makes things for end users unusable.
This is generally a characteristic of NFS, SMB or SSHFS. So as a result, we have spent time thinking about either volume mounts or rsync into the workspace to avoid this limitation.
I am going to think a lot about this on my holiday - but this general use case I believe is very essential to our future.
Going to close this issue as we are going to work on a formal Che on Kubernetes packaging, which will make use of persistent volumes to handle these scenarios. Lots of work already being done within RHT on this. You will want to follow how Che unfolds.