Systems without FUSE can't use workspaces #596
Comments
|
In GitLab by [Gitlab user @knownexus] on Aug 20, 2018, 16:01 changed the description |
|
In GitLab by [Gitlab user @sstriker] on Aug 20, 2018, 23:47 Isn't this related to a full native client, rather than a native remote execution only client? In the case of remote execution, FUSE should never be needed, regardless of workspaces. Correct me if I'm wrong, but it seems that this should not be a blocker for #412. |
|
In GitLab by [Gitlab user @knownexus] on Aug 21, 2018, 10:31 [Gitlab user @sstriker] As far as i can tell (Having spoken to a couple of the remote execution guys) workspaces can't be done through remote execution, so if we want them usable on Windows WSL, we'd need them to somehow be supported natively I may be wrong about this, i haven't had time to look into the fine details yet |
|
In GitLab by [Gitlab user @juergbi] on Aug 21, 2018, 10:54 While the remote execution development branches don't support workspaces at this point, I don't see why we can't support this in the future. It will require uploading the workspace contents to the CAS server and we need to look into file timestamp handling for incremental build support, but I expect us to support this. FUSE is only needed for local builds. While there could be environments where we want to execute non-workspace builds remotely and workspace builds locally, this is a separate question. If/when we support local builds on WSL, I also expect local workspace builds to be supported, but we can't support local workspace builds before general local build support. In any case, FUSE is not relevant for #412. Either the initial WSL version will lack workspace support, or it will block on supporting workspaces for remote execution. |
|
In GitLab by [Gitlab user @knownexus] on Aug 21, 2018, 11:06 Is which case i guess the question is, |
|
In GitLab by [Gitlab user @sstriker] on Aug 21, 2018, 12:11 [Gitlab user @knownexus] We accept that we don't have them yet and go ahead. The point is that when we have workspace builds in the remote execution branches, we should support them on WSL and OS X as well. |
|
In GitLab by [Gitlab user @sstriker] on Aug 21, 2018, 12:12 I think we can safely close this issue, as FUSE is not a factor in remote execution. |
|
In GitLab by [Gitlab user @sstriker] on Aug 21, 2018, 12:12 closed |
See original issue on GitLab
In GitLab by [Gitlab user @knownexus] on Aug 20, 2018, 16:00
Summary
If a system does not have FUSE, it's seems to be unable to use workspaces.
This is an issue as certain platforms E.G. Microsoft's WSL (Windows Subsystem for Linux), do not support FUSE.
This is a blocker for #412
Steps to reproduce
Run buildstream tests on a windows machine using WSL, All workspace related tests should fail.
Alternatively, attempt to run
bst workspace open [element] [dir]on WSLWhat is the current bug behavior?
You will get an error which states:
`Creating new namespace failed, likely because the kernel does not support user namespaces. bwrap must be installed setuid on such systems
What is the expected correct behavior?
The tests shoulds all pass
Workspaces should be successfully opened
Relevant logs and/or screenshots
https://pastebin.com/yPHdcbcJ
Possible fixes
Other relevant information
The text was updated successfully, but these errors were encountered: