## What Estimating the scope of removing our dependency on DWO, and reimplementing what it does from scratch against the K8s API. ## How 1. Create an estimate for the LOE for feature parity 1. Consider re-using the code from Server Runtime that handled what the DWO was doing for us ## Guideline to modify this section 1. Start a separate thread of any new topic you want to discuss(add/modify/delete from this issue description) 1. Make changes to this issue description with the conclusion 1. Add an update in the resolved thread that the issue has been updated with what has been discussed in the said thread --- ## Analysis ### Using devfile library DWO does not use the devfile library but implements its own logic to convert devfile into k8s resources. The first and foremost criteria would be to understand/evaluate cases where the devfile will be handled differently in the devfile library and DWO. This can be achieved by understanding the devfile library and DWO devfile handling codebase and reaching out to devfile folks amongst other things. If that looks good we are good to proceed. However, we have to make sure **we implement E2E testing with different devfile scenarios and test they behave as per specification**. Example of a scenario we need to check how devfile library handles - [inlined kubernetes components](https://devfile.io/docs/2.2.0/adding-a-kubernetes-or-openshift-component) - How to get these resources to create? Should we support them? What happens if the resource is a CRD? ### Features to build to remove DWO dependency **Legend** * :white_check_mark: - We've figured out the solution and/or we have a reference implementation available * :question: - Don't know yet how will we implement it * :thinking: - Need to discuss more #### Available in DWO and required to implement it immediately - :white_check_mark: Injecting editors - Server Runtime and DWO reference implementation are available - :white_check_mark: Injecting git credentials and config - Server Runtime reference implementation - :thinking: Workspace should only be marked ready for traffic once everything is properly set - volumes provisioned, health checks passed for both the editor and the application being run - Need to discuss - :white_check_mark: Cloning projects from git and zip sources - Server Runtime and DWO reference implementation are available - :white_check_mark: Set appropriate pod security context - Set the right parameters in the deployment config - :white_check_mark: Injecting devfile API reserver env vars - $PROJECT_ROOT, $PROJECT_SOURCE, etc. - Set the right env variables in the deployment config after reading the devfile API - Not sure if they are already handled by the devfile library - :white_check_mark: :thinking: Injecting common metadata variable as environment varialbes or mounted files - original devfile, processed devfile, flattened processed devfile, workspace name, workspace owner, ga4k agent id, cluster host suffix, etc. - Set the right env variables in the deployment config - Need to discuss behaviour on whether things like devfile should be mounted or not and if they should be then any changes to them should result in the workspace restart or not(accordingly they should be mounted as environment variable or file) - :question: :thinking: Properly managing lifecycle of all associated resources especially during deleting without which workspace deletion should not be marked completed e.g. volumes - Need to discuss failure modes and how to recover from them - :question: :thinking: Check if the workspace has not progressed for longer than the configured startup timeout - Need to discuss - :question: :thinking: Recognize kubernetes events that should fail workspace startup if they occur related to a workspace pod e.g. FailedPostStartHook, FailedMount, FailedScheduling, FailedCreate, ReplicaSetCreateError, FailedCreate, CrashLoopBackOff, ImagePullBackOff, CreateContainerError, RunContainerError - Need to discuss - :white_check_mark: :thinking: TLS Certificate generation - Server Runtime and GitLab Pages reference implementation are available - Need to discuss how and where will the certificates be stored and certificate regeneration in case of expiry(maybe issue a certificate for long duration to kick down the problem of certificate expiry?) #### Need to implement immediately regardless of DWO or not - :white_check_mark: :thinking: Provisioning cloud volume for each workspace - [Create storage class with cloud provisioners](https://kubernetes.io/docs/concepts/storage/storage-classes/) - Need to discuss what the config will be for various clouds and how should we create this (maybe [`prerequisites` loop that agentk](https://gitlab.com/gitlab-org/remote-development/gitlab-remote-development-docs/-/blob/main/doc/architecture.md#types-of-messages) has? - :white_check_mark: :thinking: Providing image pull secrets - Need to discuss how will image pull secrets be provided - a pre-defined secret in a particular namespace that the cluster administrator has to ensure is available. Maybe the agentk checks the existance of this during the `prerequisites` loop? - :white_check_mark: :thinking: Exposing endpoints for public/internal/private access - Need to discuss authentication and authorization strategy. This is a different and big topic altogether. As far as this issue is concerned, the only point to consider is how it will affect the architecture. - :question: :thinking: Discuss various failure modes - storage not getting provisioned in cloud or storage not being deleted due to cloud APIs not working, volume mounting errors due to them being in different availability zones etc. - :white_check_mark: :thinking: SSH into workspaces - Server Runtime reference implementation is available - Need to discuss how and where will the SSH keys be stored and the authentication/authorization mechanism #### Available in DWO but not required to implement it immediately - :thinking: Mounting existing k8s resources like configmap/secret as env/file/volume with subpath properties and auto-reloading them in the workspace when they are changed - Do we require this? - :question: :thinking: Idle workspace timeout - :question: :thinking: Reconciliation of workspace resources - if something changed by someone other than agentk, we want to revert it - :question: :thinking: While flattening the devfile, add source attributes like 'controller.devfile.io/imported-by=sourceID' to all elements of a plugin that support attributes. This helps in transparency around which project/command/component is derived from where in a multi-level devfile - :question: :thinking: Stopping constantly failing/crashing workspaces and providing a way to override this stopping to allow for debugging - :thinking: Multiple volume options - ephemeral volumes, same volumes for multiple workspaces - Some workloads/organizations may require mounting the same volume(e.g. [AWS EFS](https://aws.amazon.com/efs/)) to multiple workspaces under different subpaths - Some workloads might be purely ephermeral where no persistant storage might be required (Need to discuss if we want to support these) - DWO supports various volume modes documented [here](https://github.com/devfile/devworkspace-operator/blob/main/docs/additional-configuration.adoc#configuring-persistent-storage-used-for-a-devworkspace) #### Available in DWO but may not be required to implement at all - Ability to override host suffix, routing class on a workspace level - :thinking: Prometheus metrics about total, starting, running, failed, startup time histogram of workspaces - Do we need this? We can get this information from information stored in Postgres #### Need to research more - :question: :thinking: How should [kubernetes components in devfile](https://devfile.io/docs/2.2.0/adding-a-kubernetes-or-openshift-component) behave in our solution, what are the use cases, etc. - Various options to handle for endpoint exposure e.g. [`secure` which puts the endpoint behind a JWT proxy](https://devfile.io/docs/2.2.0/defining-endpoints)