Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[che-dev] Tooling Containers vs. Runtime Containers

Hi folks,

just wanted to make you aware of a discussion I had today with Mario Loriedo & Florent Benoit. We talked about debugging processes using Che 7 plugins. In particular reusing debugger extensions from VSCode. During this discussion, we noticed that we had different ideas about what should be in a tooling container. My opinion was that the tooling container should contain only what is necessary to run the tooling, not what is necessary to run the target application. Mario argued that it should (in the simple case) also contain the runtime for the application. Let me make an example using PHP. The example is not realistic, it's just to illustrate. Let's assume we want to debug a PHP program. The debug adapter for PHP is written in Typescript, and as such does not need a PHP engine. Which containers would we have in the Che 7 workspace and which software would they contain?

1. Tooling only


1. Runtime Container
- PHP installation

2. Theia container
- NodeJS
- Theia IDE

3. PHP Tools Sidecar
-Node runtime
-Theia plugin host (a nodejs program
-PHP debug adapter theia plugin

Notice the absence of PHP in the tooling sidecar: since the debug adapter does not require it to run, it's not included. There are two advantages to this configuration: First, the runtime container is closer to what the user is going to use in production: The tooling container is likely added to the workspace by downloading a Che plugin from the Che marketplace. There is a likelihood that it has little to do with the production container the user wants to run in the end. The second advantage is that when we have multi-language projects, we can mix and match tooling and stuff will still work: imagine the php project wants to run a Java program as part of it's workload: As long as the user has both tools installed in his target container, the tooling will work.
The downside is that our tooling may have to be container-aware: if the debug adapter tries to run the php program locally, it will try to run it in the tooling sidecar container, whihch does not even contain a PHP runtime. It needs special code that will run the php program in the runtime container.

2. Tooling & Runtime


1. Theia container
- NodeJS
- Theia IDE

2. PHP Tools Sidecar
- Php runtime
- Node runtime
-Theia plugin host (a nodejs program
-PHP debug adapter theia plugin

Notice the php runtime in the sidecar. The advantage of this setup is that runtime and tooling run on the same container: this will allow to reuse a greater amount of preexisting code. Supposedly, it's also simpler for the user (which I personally don't agre with: in my vision, people will not create che 7 workspaces by hand, but by selecting a target environment and the tools the want from the Che marketplace). The disadvantages are the we lose the mix-and-match capability for multiple languages and that the developoment environment may be very different from our runtime environment (something che 7 was supposed to improve)

While this is not an issue we need to decide right now, it will inform how we write plugins for Che, so I think it's an important that the relevant parties get aligned on a common vision.

/Thomas

Back to the top