Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cloud Shell Che Workspace #15434

Closed
22 of 38 tasks
l0rd opened this issue Dec 9, 2019 · 3 comments
Closed
22 of 38 tasks

Cloud Shell Che Workspace #15434

l0rd opened this issue Dec 9, 2019 · 3 comments
Labels
kind/epic A long-lived, PM-driven feature request. Must include a checklist of items that must be completed.

Comments

@l0rd
Copy link
Contributor

l0rd commented Dec 9, 2019

This epic is about the technical work needed to implement a cloud shell component that would be used on OpenShift Console:

image

Using the DevWorkspace CRD

The cloud shell should use the DevWorkspace CRD that is described in #15425

image

Using a new CheEditor

A Theia based Che workspace is a waste of compute resources if used only to get a terminal. And it takes way too long to bootstrap. So the idea is to implement an alternative cheEditor and a cloud shell workspace could be defined using the following devfile:

 ---
apiVersion: 1.0.0
components:
- type: cheEditor
  id: redhat/cloud-shell/latest
- type: dockerimage
 image: quay.io/eclipse/openshift-tooling:latest

Other considerations

  • Exec denial: exec into the pod should be denied for any user other than the owner
  • Auth: The terminal service should be secured using OpenShift OAuth and RBAC
  • Autoscale to zero: After a few minute of inactivity cloud shell pods should be deleted

Subtasks

Timeline

2020-03-31 (Che v7.11.0)

2020-04-20 (Che v7.12.0)

  • Solve the problem with the OpenShift OAuth Proxy: how can we avoid to re-authenticate users? Is it possible to use the existing Console Proxy? And avoid the creation of a route per cloud shell?
  • Release the first version of the che-workspace-operator based on the devworkspace-api (there is no need to publish to the Operator Hub yet) and that includes the solution proved to work in the previous iteration.

2020-05-12 (Che v7.13.0)

2020-06-02 (Che v7.13.0)

  • Include the build of the che-workspace-operator and devworkspace-api in the CRW build
  • Publish the cloud shell operator on the Operator Hub
  • Include the CloudShell e2e happy path test in the QE team CRW release validation check CloudShell Happy Path Test #16667
  • [OPTIONAL] Add a che property to switch using the DevWorkspace API instead of the Kubernetes infrastructure to create Devfile based Che workspaces. That will allow to start testing the creation of DevWorkspaces using the Che dashboard and other wsmaster clients.

2020-06-18

  • OpenShift 4.5 is release with CloudShell support based on DevWorkspace operator.
@l0rd l0rd added the kind/enhancement A feature request - must adhere to the feature request template. label Dec 9, 2019
@che-bot che-bot added the status/need-triage An issue that needs to be prioritized by the curator responsible for the triage. See https://github. label Dec 9, 2019
@ibuziuk ibuziuk added kind/epic A long-lived, PM-driven feature request. Must include a checklist of items that must be completed. and removed kind/enhancement A feature request - must adhere to the feature request template. status/need-triage An issue that needs to be prioritized by the curator responsible for the triage. See https://github. labels Dec 9, 2019
@ibuziuk
Copy link
Member

ibuziuk commented Dec 9, 2019

@l0rd according to the description this is an epic, but I'm not sure which team label should be applied

@ibuziuk ibuziuk added this to the Backlog - Epics milestone Dec 9, 2019
@AndrienkoAleksandr AndrienkoAleksandr self-assigned this Dec 9, 2019
@davidwindell
Copy link
Contributor

It would be awesome to be able to do this from the Che dashboard too - so one could quickly make a change to a project without booting the whole IDE up.

@sleshchenko
Copy link
Member

I believe that the functionality described in that epic is already implemented.
There are only some fixes are done before release and it's needed to productize WebTerminal but there is another epic to track release related tasks and dependencies #17084

I'm closing it let me know if you think it makes sense to keep it open

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/epic A long-lived, PM-driven feature request. Must include a checklist of items that must be completed.
Projects
None yet
Development

No branches or pull requests

7 participants