[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [che-dev] Maybe it's time to admit
|
I think one way to take a half-step in the right direction, at least
from the "number of containers in a workspace" perspective, is to get a
little fancier with what containers we ship. Currently, Che is set up so
that you can very easily add e.g. Go tooling to your Java workspace.
This is reflected in our design but is probably a <1% use case.
Two things that I think are worth considering and relatively easy to do are:
* Package "spins" of the Theia container, such as che-theia-java,
che-theia-go, etc. This would allow you to easily run the IDE component
of single-language workspaces in effectively a single container and
remove the requirement for those sidecars to exist.
* Run plugins that depend on che-sidecar-node in the Theia container. As
far as I know (apart from node versions), we're not really doing
anything to these containers (e.g. [1]).
The two ideas above would require a bit of work (building+maintaining
new images, but also see [2]) but I don't think it's a huge burden given
that we already maintain the images involved.
The major downside, though, is that it introduces a dependency between
plugins/editors in a devfile. Thus far we've focused on the flexibility
that sidecars give us -- plugins are self-contained and guaranteed to
work since they come with their own dependencies. This may be a
significant enough philosophical change to block the points above, but I
think it could also be viewed as reinforcing our core workflows. The
current functionality would still exist (you could always use the "base"
theia and a sidecar-based java plugin as we do currently).
I know we're averse to breaking the "one application per container"
general rule of thumb, but it does sometimes feel like what we're doing
is dividing one application into multiple containers.
[1] -
https://github.com/che-dockerfiles/che-sidecar-node/blob/master/Dockerfile
[2] - This would require updating the plugin meta.yaml spec to allow
specifying a memory/cpu requirement for non-sidecar plugins [3] and some
work in the plugin broker to take it into account.
[3] - https://github.com/eclipse/che/issues/14511
- Angel
On 10/6/20 7:17 PM, 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?
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)
The VM approach leads to snowflakes, non repeatable environments (new
dev on boarding takes time)
The VM approach moves away devs from ops (they do not share a clear
contract)
The VM approach doesn't scale (it takes time to switch between multiple
dev environments)
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.
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.
[1] https://github.com/eclipse/che/issues/15966
[2] https://github.com/eclipse/che/issues/15373
On Tue, Oct 6, 2020 at 4:20 PM Aurélien Pupier <apupier@xxxxxxxxxx
<mailto:apupier@xxxxxxxxxx>> wrote:
Hi,
On Tue, Oct 6, 2020 at 4:04 PM Eric Williams <ericwill@xxxxxxxxxx
<mailto: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 <mailto:che-dev@xxxxxxxxxxx>
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev
--
Aurélien Pupier
Principal Software Engineer, Fuse Tooling
Red Hat France <https://www.redhat.com/>
apupier@xxxxxxxxxx <mailto:apupier@xxxxxxxxxx> IM: apupier
<https://www.redhat.com/>
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx <mailto: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
