[Spike] Shared workspaces
Description
There's some use cases where it'd be nice for different GitLab users to seamlessly connect to the same workspace. This brings up a lot of architectural considerations:
- How do we represent that a workspace is owned by a "Project" (or a system user of the "Project") and available to a subset of users (possible based on access level).
- How do we dynamically provision and secure multiple users within the running container?
Considerations / Questions
...
Spike Objectives
...
Future Tasks
...
Context
-
Context: “Think Big” idea “What if we had Review Workspace vs. Review Apps for Merge Requests”? This implies a “shared” workspace where multiple users can hop on.
- A “shared” workspace implies that we need the user connected in the workspace (i.e.
whoami
) to represent the GitLab user (not necessarily the user that created/”owns” the workspace). - We can’t necessarily know the possible set of users ahead of time, so this implies the need for us to do a
useradd
on the workspace to provision a secure sandbox for that specific user in the workspace. - For us to dynamically provision container users, we’ll need to run commands in an existing workspace, triggered by the Rails app whenever the user is requesting to connect…
-
brainstorm: For us to run commands in the existing workspace, what if we had a CLI tool that could be included in every workspace? Rails could execute this CLI tool through
ssh
as the system user that owned the workspace.
- A “shared” workspace implies that we need the user connected in the workspace (i.e.
-
Notes from sync discussion document (internal): https://docs.google.com/document/d/1C4iOFmNDTQV--kbO9RPPwdd2fwyleiE-H1XGjwNWIEM/edit#heading=h.6v0tbiqtovs5
Edited by Chad Woolley