[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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).
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)
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.
The VM approach leads to snowflakes, non repeatable
environments (new dev on boarding takes time)
Nope, you could still have repeatable environment via devfile, just
that you would include a runtime image for Theia and the installed
extensions
The VM approach moves away devs from ops (they do not
share a clear contract)
Explain please?
The VM approach doesn't scale (it takes time to switch
between multiple dev environments)
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 makes it harder to deploy the target app
on modern cloud platforms (kubernetes)
I fail to see how that would be the case.
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
Hi,
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