Workspace.Next

[gorkem]

Workspace.Next epic is the container for the infrastructure and workspace definition changes that are targeting to improve how we create and run Che workspaces.

The goals of Workspace.Next

• Improved multi-container application support
• Workspace definition integration with 3rd party tools
• Abstraction of runtime container(s) from tools
• Interfaces for workspace management

Improved multi-container application support

Extend the multi-container workspaces to support use-cases that are more common today.

Beyond single application workspace

Although it is true that a single application should be deployed to a single container, there are cases where two applications can be modified or debugged together. Workspaces should be able to handle multiple containers deployed to distinct containers.

Use standard services

It should be possible to refer to standard services provided by service brokers on workspaece definitions and deploy them along side Che workspaces. For instance a developer should be able to use catalogs such as the Openshift service catalog to add services such as databases to its workspace.

Subtasks of multi-container application support

• Support for multiple applications on a workspace Support for multiple applications on a workspace #7642
• Ability to provision workspace containers via Open service broker API
• Extend workspace definition to include references to services

Workspace definition integration with 3rd party tools

Che Workspace Engine

Che workspace engine is a new component that runs as part of the ws-master. Its goals are

1. Understand 3rd party tools/artifacts and convert them to workspace definitions
2. Export workspace definitions to 3rd party tools/artifacts
3. Create workspace definitions for established application types
4. Define a single Che specific workspace definition artifact

One can imagine the workspace engine as a translator and mapper between the 3rd party tools infrastructure, and the workspace definition.
Examples of such 3rd party tools and artifacts are kubernetes yaml, helm charts, etc.

Subtasks of the Che Workspace Engine

• Convert 3rd party artifacts to a workspace definiton Convert between 3rd party artifacts and workspace definiton  #7641
• Generate 3rd party artifacts from workspace definition Convert between 3rd party artifacts and workspace definiton  #7641
• Create workspace definitions for established application types
• Consolidate and improve chefile and factory.json see Consolidate Chefile and Factory formats #4362

Abstraction of runtime container(s) from tools

The basic idea is made by running developer tooling around user application without installing anything inside of user container. User consumes tools as a set of features provided by microservices running inside of Linux containers.

Since we would like to position Eclipse Che as future development platform
we can't lock in some specific language or development flow. The goal of new abstraction
is to provide tooling framework to implement existing and future development flows
in native container way. Examples of completely opposite development approaches and requirements.

1. NodeJS aka frontend developers expect to have quick turnaround development when their changes compiled
   on the way and reloaded just after they are saved on disk. That means we can't go in a long and reproducible way when we have building sources from a scratch producing some result artifacts and packaging it in a container and restart the whole application to make sure it's 100% reproducible.

2. Traditional Java can decide to use some longer flow. When major development time spends with unit testing, but when core functionality of the application is ready they want to produce an image with compiled artifacts and run the application from the scratch.

Features

A feature is a list of services (with optional) configs that it provides. Features can deliver multiple services irrespectively of their role in client-server architecture. For example, a feature may provide language server as sidecar + IDE plugins compatible with this LS, or, say, LS or IDE plugin alone. Currently, language server, terminal, and Theia plugins are something that we can realistically imagine.

Features bring together server and client side services.

End users will deal with features only. Developers will deal with features and services.
Services
A service defines a container or a set of containers that provide certain server and client side component - language servers, proxies, standalone servers with API, IDE plugins. Services have recipes that are dockerimage, yaml etc. Image tags can be used for versioning.

Workspace

We see a workspace as a place where we combine application source, deployment configuration, and development tooling. Tooling will be provided by features.

Implementation plan

Since we are not fully confident in Workspace definition because some points have to be studied and discussed we would like to use an iterative approach to implementation.

Phase 1.

We will store features list in workspace 6 attributes + we will teach Kubernetes/Openshift infrastructures to adjust workspace runtime with containers that are come from features.
Here #9292 we are going to discuss object details

• Define abstraction level above workspace service layer Abstraction level above workspace service layer #8703
• Workspace.Next/Phase 1 - CheService/CheFeature model Workspace.Next/Phase 1 - CheService/CheFeature model #9292

Phase 2.

We are going to collect feedbacks, revise workspace model.

I believe that this is a safer approach to start deliver smaller pieces instead of long discussion.
Moreover, it's not limiting us to discuss details of Phase 2 during Phase 1 implementation

Subtasks for Abstraction of runtime from tools

• Adapt ws.next model to new requirements Adapt ws.next model to new requirements #9895
• ws.next walking skeleton ws.next walking skeleton #10123

Interfaces for workspace management (3I&F)

Che workspace management functionalities shoud be accesible through API, CLI, UI and Factories (3I&F)

REST APIs

These are the entrance into the Che workspace engine which are to be used by 3rd party integrations as well as CLI and editor.

CLI

Command line to create a workspace.

• import from kubernetes.yml
• export as kubernetes.yml
• create workspace from che_workspace.yml
• create a workspace for a well known service for instance create a workspace for spring boot.
• Add/remove containers to a workspace
• modify tools on an existing workspace

Some example commands

che workspace create -f che_workspace.yml
che workspace create -f myk8s.yml
che workspace export -o k8s
che workspace create -s spring_boot
che workspace modify add -agent yaml_support -agent json_support -w myworkspace

Factory

Add new factories or extend the existing ones like to expose the new capabilities of the engine for creation of workspaces.
See: #9879

User Interface

This is the graphical editor for editing essentially the workspace model. However since a workspace model can easily be converted into an infrastructure model and exported it can also serve as the graphical, drag-n-drop editor for infrastructure models.

Subtasks

• Define and implement CLI
• Graphical editor for editing workspace
• Improve add new Factories

[skabashnyuk]

Idea

The basic idea is made by running developer tooling around user application without installing anything inside of user container. User consumes tools as a set of features provided by microservices running inside of Linux containers.

Since we would like to position Eclipse Che as future development platform
we can't lock in some specific language or development flow. The goal of new abstraction
is to provide tooling framework to implement existing and future development flows
in native container way. Examples of completely opposite development approaches and requirements.

1. NodeJS aka frontend developers expect to have quick turnaround development when their changes compiled
   on the way and reloaded just after they are saved on disk. That means we can't go in a long and reproducible way when we have building sources from a scratch producing some result artifacts and packaging it in a container and restart the whole application to make sure it's 100% reproducible.

2. Traditional Java can decide to use some longer flow. When major development time spends with unit testing, but when core functionality of the application is ready they want to produce an image with compiled artifacts and run the application from the scratch.

Features

A feature is a list of services (with optional) configs that it provides. Features can deliver multiple services irrespectively of their role in client-server architecture. For example, a feature may provide language server as sidecar + IDE plugins compatible with this LS, or, say, LS or IDE plugin alone. Currently, language server, terminal, and Theia plugins are something that we can realistically imagine.

Features bring together server and client side services.

End users will deal with features only. Developers will deal with features and services.
Services
A service defines a container or a set of containers that provide certain server and client side component - language servers, proxies, standalone servers with API, IDE plugins. Services have recipes that are dockerimage, yaml etc. Image tags can be used for versioning.

Workspace

We see a workspace as a place where we combine application source, deployment configuration, and development tooling. Tooling will be provided by features.

Implementation plan

Since we are not fully confident in Workspace definition because some points have to be studied and discussed we would like to use an iterative approach to implementation.

Phase 1.

We will store features list in workspace 6 attributes + we will teach Kubernetes/Openshift infrastructures to adjust workspace runtime with containers that are come from features.
Here #9292 we are going to discuss object details

Phase 2.

We are going to collect feedbacks, revise workspace model.

I believe that this is a safer approach to start deliver smaller pieces instead of long discussion.
Moreover, it's not limiting us to discuss details of Phase 2 during Phase 1 implementation

[garagatyi]

I like iterative approach to check new architecture. Thank you for the explanation and sharing.

[gorkem]

updated the description with @skabashnyuk suggestion.

[garagatyi]

We should also address feature commands fetching issue #9546

[0Grit]

Really glad to see a multi container workspace approach.

Has any thought been given towards embedded development scenario's?

• For single board computer applications we can potentially debug by deploying to a container running qemu or even docker running on the real target. However, the more likely scenario will involve SSH, GDB, and a real embedded target.

• For MCU applications we'd need to deploy via debug server connected to jtag debugger.

If ease of implementation for the above were improved, the barrier to entry for embedded and Iot Endpoint software development would be greatly reduced.

[porcelli]

@gorkem based on our conversation last week, I understand that Theia was a R&D, but you ended up choosing VSCode Monaco, correct?

[gorkem]

@porcelli We are using Theia, which also includes Monaco, that is what I meant.

[porcelli]

@gorkem gotcha! thx

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.

[gorkem]

I think this is largely done now and we have improvement items.