**TRACKING ISSUE: https://gitlab.com/gitlab-org/gitlab/-/issues/386840+** ## Goal - Update spike branch with graphql endpoints in Rails to allow user to create, update, and view workstations - Chad - Update spike branch with Vue component(s) hooked to graphql endpoints, to expose current functionality in spike via GitLab UI. This will support easier and more efficient local testing and product demos - Chad - [Poll Rails for work from agentk](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/master/doc/architecture.md#high-level-architecture) - Vishal / Chad - Add authentication and authorization to the workspaces created in the kubernetes cluster. - Vishal / Tomas - Build editor injector for GitLab fork of VS Code - Tomas **previously: Authenticate/Authorize traffic and use GA4K for communicating with Kubernetes API** Tracking Issue: https://gitlab.com/gitlab-org/gitlab/-/issues/386840+ as a SSoT for the work being completed until we can effectively split the work into issues. ## Requirements - Our assumptions around https://gitlab.com/gitlab-org/remote-development/gitlab-remote-development-docs/-/blob/main/doc/architecture.md are validated and working. These are **not** part of the MVC: - Integration of Remote Development to the GitLab UI and Web IDE - Using GA4K instead of ingress controller ## Assumptions - https://gitlab.com/gitlab-org/gitlab/-/issues/377921+ - https://gitlab.com/gitlab-org/gitlab/-/issues/383020+ ## Questions - TBA ## User Prerequisites - ## Success criteria - [Poll Rails for work from agentk](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/master/doc/architecture.md#high-level-architecture) - Rails endpoints to create/delete/get/list workspaces. - All requests are correctly authenticated and authorized (except those where the user has requested the traffic to be public e.g. opening a server while developing and making it public). - A user can create a workspace, start a server on that workspace and have that traffic become private/internal/public. - We are using GitLab fork of VS Code as the editor. ## User Value - Support for VS Code as the primary editor - Define a remote environment in a file hosted in a project repository - Rails endpoints to create/delete/get/list workspaces - Users can create a workspace, start a server on that workspace and have that traffic become private/internal/public. ## Limitations - kas will make two types of requests via its polling schedule: 1) POST requests - kas will send Rails some updated information (which it has received from agentk), and 2) GET requests - kas will receive work requests from Rails (which it will pass on to agentk) . For now, the assumption is that these will be both be to a single internal endpoint, e.g. /remote_dev (can be whatever we decide) - The kas POST requests will pass information (via JSON request body) to Rails to persist any updated actual_state values for environments, in addition to other necessary/updated environment metadata. These would be cheap/performant “no-op” actions if there is no updated info to persist for the current poll. If this turns out to be too much/too frequent load for the API under a polling approach, we can revisit, but for now we will go with this as the simplest solution, and not attempt to prematurely optimize.