-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
DevWorkspace Switch - Endgame Plan #20830
Comments
@skabashnyuk @azatsarynnyy @svor @tolusha if you haven't yet please update the TASKS with your milestone 3 issues |
done |
Hello Mario, A couple of notices to consider:
Next capabilities look also critical / blocker, IMHO:
|
Thank you @dmytro-ndp, this is great. |
@l0rd: it's clear that we are going to support conversion of workspaces with devfile v1, linked to github projects, to devfile v2 (an issue #20784). How about conversion of workspaces with devfiles v1, which have been obtained code from zipped project, keeping source code in persistent storage and devfile content in Che PostgreSQL database ? What will user be needed to do in order to start such devfile v1 workspace again after DevWorkspace switch? |
I don't think we need to worry about workspaces loaded from sample project code (dashboard devfile tiles). But we DO need a story for these two possible paths when updating to 2.15 / DW enabled:
If we can't warn users / admins clearly enough that turning on DW will prevent access to unsaved workspace changes... then we need that second option. |
Converting che-server workspaces should use the 'stored definition/model' so there is no specific 'zip project case' |
@benoitf: I meant zipped project case like:
|
@dmytro-ndp I still don't see why it's a particular case. |
@benoitf: it's about non-factory flow, when devfile content is created in User Dashboard and stored into Che PostreSQL database. About zip project type https://www.eclipse.org/che/docs/che-7/end-user-guide/authoring-devfiles-version-1/#adding-projects-to-a-devfile_che
AFAIK, converter v1 > v2 works with factory flow only, when user starting workspace using factory URL, and with project type github in devfile. I am curious about how conversion v1 > v2 will work for workspaces without project, or with project without devfile.yml in source code. |
The converter library takes a devfile v1 object as input so you can convert a devfile of an existing workspace (no matter of git, github or zip) |
Maybe he's asking about dirty workspaces w/ code that was previously imported from the v1 devfile? I assume for devfile samples listed in the Dashboard, there's no expectation that dirty workspace changes to a sample project will be persisted / supported after conversion to v2.1. And for fresh workspaces created from new samples... well, they'll use the v2.1 devfiles instead, and will import the project from whatever is specified (git, zip, etc.) But I suppose the UX challenge here is that if an ADMINISTRATOR performs the steps to manually update from CRW 2.14 / Che 7.40 (devworkspace disabled) to CRW 2.15 / Che 7.42 (devworkspace enabled) there's no way to communicate to USERS that all their old workspaces (be they personal, custom, or from a sample in the devfile registry) will be inaccessible after the switch is flipped to enable DW, and no way for users after the fact to access any unsaved changes. So maybe we can mitigate this with a big warning in the CSV text of the 7.42/2.15 operator reminding admins that there's no way to go backwards and re-open workspaces that have been cut off after the switch to enable devworkspace? |
@benoitf: let's say I have workspace v1 with zip project. |
@l0rd: will Eclipse Che continue supporting DevWorkspace disabled mode (with devfile v1, and back conversion v2 > v1) from 7.41.0? |
@dmytro-ndp no it won't be supported anymore. |
@l0rd: could you, please, say, if there will by multi-host support in DevWorkspace, or there will be single-host support only? |
@dmytro-ndp single-host only |
@l0rd: will DevWorkspace Step 3 support analytics plugins for java, NodeJs and Python? |
@dmytro-ndp that should works as it doesn't use che-server API. @svor can you confirm? |
It should work |
@l0rd, @svor: thanks for the answer! @SkorikSergey: cc ^^ |
Attempted this with Che dogfood cluster + https://che-dogfooding.apps.che-dev.x6e0.p1.openshiftapps.com/#https://github.com/redhat-developer/devspaces-images Does not seem like the UDI image is available on workspace load -- I only get one choice for a terminal, and it doesn't know what java is. Also, it's an Alpine container, not a UBI8 based UDI image.
|
Closing this issue. The switch to DevWorkspace operator happened in Che v7.42 release. |
Is your enhancement related to a problem? Please describe
This epic is supposed to replace the DevWorkspace STEP 3 milestone. It lists the issues required to switch from the che-server to the DevWorkspace, as well as the acceptance criteria to check .
ACCEPTANCE CRITERIA
Green field deployment and configuration
stable
channel uses “all-namespace” install mode (one instance per cluster). Channelstable
is the only channel for Che. It’s NOT possible to disable DevWorspaces. Kubernetes 1.21 (OCP 4.8) or higher is requiredchectl
commands that interact with che-server or related to devfile v1 are removedchectl
deploys dex automatically, on OCP the integrated OAuth service is used)Upgrading an existing instance
chectl
)Dashboard and "Getting started"
Workspace startup
and the Universal Developer Image as the develpment/tooling containerWorkspaces features
Enterprise features
Telemetry
Monitoring
Documentation, website, and blog
TASKS
Deployment
Upgrading an existing instance
DevWorkspace
Running
toStarting
devfile/devworkspace-operator#618Dashboard
Monitoring
Plugins
Devfiles
Che-server
OUT OF SCOPE (ADDRESSED IN FUTURE RELEASES / ORDERED BY PRIORITY)
kubernetes
andopenshift
components #17894ServiceAccount
(the DW controller can specify the default SA SCC instead)The text was updated successfully, but these errors were encountered: