| Re: [che-dev] Maybe it's time to admit |
On 07/10/2020 01:17, Mario Loriedo wrote:
One container per plugin is NOT a good idea. But that's something we have been discussing in the past. We have discussed how to mitigate it too [1] and running multiple plugins in one container is currently possible [2].
Anyway I think that what Thomas is trying to challenge is the choice to use a sidecar approach rather than a VM like approach for development environments.
Is it the right moment to discuss it? Probably not. We are suuuuper busy with our tight release schedules.But will we ever have a "right moment" to discuss? Probably not so....
So why aren't we using a VM-like dev machine with a predefined set of tools and runtimes? A machine where a user could even install his favorite tool or a different version of one of the runtimes available there. UX would be similar to local machines and developers would feel at home right?I am _not_ advocating having a single dev machine. I am advocating running the whole Theia ide in one container. That theia IDE would run in a container that has all the tools needed to run the plugins installed. There would still be a "dev-machine" container and if you like a "target runtime" container (something we don't have in most devfiles at the mometn).
_______________________________________________none of our current devfiles include a specific "production" container, so even now that is the case. Nothing in what I propose would prevent that.Right. But this approach has some issues too and here is a list:
The VM approach augment the divergence between dev and production (works on my machine)
Nope, you could still have repeatable environment via devfile, just that you would include a runtime image for Theia and the installed extensionsThe VM approach leads to snowflakes, non repeatable environments (new dev on boarding takes time)
Explain please?The VM approach moves away devs from ops (they do not share a clear contract)
It's the current release that does not scale: we are spending oodles of time becoming familiar with particular plugins in order to work around the limitations of our current approach. And no, switching to a different dev environment (dev file, I assume) works the same as now. Maybe I don't understand what you mean here.The VM approach doesn't scale (it takes time to switch between multiple dev environments)
I fail to see how that would be the case.The VM approach makes it harder to deploy the target app on modern cloud platforms (kubernetes)
These aren't new arguments. The twelve factors app methodology and the ultimate success of containers are based on principles that address the VM approach. But dev tools haven't been fully adapted (yet) to this new paradigm and Thomas has mentioned a list of downsides of the sidecar approach.I don't see how https://12factor.net/ offers any guidance for Che: for starters, our app is very much stateful. If we want to make development more like a typical web app, we would have to rearchitect the system from the ground up. Approaches have been investigated for a long time (see "beyond sniff" (https://www.ubilab.org/publications/print_versions/pdf/see95.pdf), for example), but that is not what we're doing: we're reusing the same technology everyone else in the space is using, and that technology (language servers and VS Code extensions) is distinctly unlike a web app. I'm unaware of anybody working on web-appy dev tools. I'd gladly lead that research project, though ;-)
Should we go back to the mainstream model then? I don't think so. Addressing the downsides of the VM approach is our key differentiator and we have a great opportunity to win. Is our sidecar model mature? I don't think so. We still have some important issues to address but we have made an amazing job exploring unknown lands and we should keep up the good work.The only downside is that the user would have to craft a theia runtime image with the necessary native dependencies installed for their own devfiles (something they gladly do for our competitors like gitpod or codespaces). If they reuse the "standard" devfiles, nothing changes for the user. In return, they get something that does not fail in mysterious ways and they can reuse all ~30000 vscode extensions. We tried and it didn't work, let's stop digging.
/Thomas
On Tue, Oct 6, 2020 at 4:20 PM Aurélien Pupier <apupier@xxxxxxxxxx> wrote:
_______________________________________________Hi,
On Tue, Oct 6, 2020 at 4:04 PM Eric Williams <ericwill@xxxxxxxxxx> wrote:
Hello,
On 10/6/20 7:07 AM, Thomas Mäder wrote:
> ...that our plugin model (contanier per plugin) is wrong:
>
> * we're investing a lot of effort into our container-per-plugin model,
> yet we can't really make it work for many vs code extensions, leading to
> weird errors and testing effort at each update
>
> * we need to run our own plugin registry with our own meta.yml, etc.,
> which is becoming a bottleneck
Some things we can do to reduce this maintenance cost:
* only one version of the plugin in the registry: we release Che often
enough that we don't need multiple versions of one plugin
* increased automation + testing (in progress)
* unify registry and sidecar image contribution process
> * we need a "dev-machine" image anyway (for example, with maven, npm,
> typescript or whatever the stack needs)
>
> * the focus seems to be on out-of-the-box experience, which could easily
> include making a specific "IDE" image per stack.
>
> * there is an effort to make the different containers invisible to the user
>
> * all other contenders in the market have a "single container for the
> IDE" model
>
> * the model only works for Theia and we seem to be starting to support
> other editors
I think there is a strong argument to be made for merging the language
sidecar and dev-machine images. Often the use cases for both of these
containers is so tightly coupled that it makes sense to combine them.
For example in Java, you'd have vscode-java (and related extensions) all
running on the java-maven dev machine container.
For non-language plugins (container tooling, for example), it still
makes sense to keep the plugins in separate containers, as there is no
overlap in the environment needed to run these tools.
Unfortunately, I think I have a use case with an overlap: for VS Code Camel K. VS Code Camel K requires VS Code Kubernetes and fits in "container tooling". But it also requires VS Code Java to provide Java completion for Camel K files (which is why the completion for Java is not still not working for Camel K files)
Eric
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/che-dev
--
che-dev mailing list
che-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/che-dev
_______________________________________________ che-dev mailing list che-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/che-dev
che-dev mailing list
che-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/che-dev