Che: [airgap] Plugins that have dependencies will fail to start in airgap mode.

[amisevsk]

Describe the bug

Upstream Theia includes functionality to download extension dependencies on workspace start (e.g. it will download vscode-yaml if starting a workspace with kubernetes-tooling). Since this download does not try to pull from the plugin registry, in airgapped scenarios Theia is unable to download extensions' dependencies, which causes them to fail to start.

Che version

• [x] nightly

Steps to reproduce

Start workspace with devfile

apiVersion: 1.0.0
metadata:
  name: plugin-dependencies
components:
  - id: ms-kubernetes-tools/vscode-kubernetes-tools/latest
    type: chePlugin

in an airgapped cluster with no access to the public internet and check plugin for failure to initialize.

Additional context

Related to https://github.com/eclipse/che/issues/15794, https://github.com/eclipse/che/issues/15730

[tsmaeder]

That resolver needs to disappear: we can't use the VS Code marketplace.

[amisevsk]

I agree, though the resolver is the only reason many of our plugins work currently.

[tsmaeder]

So two bugs cancel each other 🤦‍♂

[tsmaeder]

@l0rd besides breaking air-gapped, this could really land us in hot water with MS.

[l0rd]

@tsmaeder agreed. If we cannot remove this resolver how can we fix the problem?

[amisevsk]

@l0rd I can prioritize supporting plugin dependencies at the broker level, that could be done relatively quickly. However, I'm still not sure if plugins support cross-container activations (if I start a workspace without the resolver and e.g. the k8s and yaml plugins, will k8s work?)

I can try to look into this further, but it's hard to test since there's no easy way to get rid of the resolver, as far as I know.

[amisevsk]

A stop-gap solution that could be implemented more quickly would be to include dependencies explicitly in each plugin as extensions, e.g. the k8s plugin becomes

apiVersion: v2
publisher: ms-kubernetes-tools
name: vscode-kubernetes-tools
version: latest
type: VS Code extension
displayName: Kubernetes
title: Kubernetes Tools
description: Develop, deploy and debug Kubernetes applications
icon: https://www.eclipse.org/che/images/logo-eclipseche.svg
repository: https://github.com/Azure/vscode-kubernetes-tools
category: Other
firstPublicationDate: '2020-01-14'
spec:
  containers:
    - image: quay.io/eclipse/che-sidecar-kubernetes-tooling:1.0.9-a40b3bb
      name: vscode-kubernetes-tools
      memoryLimit: 1G
  extensions:
    - https://download.jboss.org/jbosstools/vscode/3rdparty/vscode-kubernetes-tools/vscode-kubernetes-tools-1.0.9.vsix
    - https://github.com/redhat-developer/vscode-yaml/releases/download/0.4.0/redhat.vscode-yaml-0.4.0.vsix # include vscode-yaml directly
latestUpdateDate: "2020-01-23"

This would resolve the issue of hitting the vscode marketplace and be quicker to implement than a full dependency resolution scheme.

[tsmaeder]

One thing to be aware of is that some VS Code extensions return an API object from their activate function. Using that will not work across process boundaries.

[JPinkney]

Just to add, VSCode-YAML is one of those extensions that returns an API object from activate

[benoitf]

we've https://github.com/eclipse/che/issues/15376 for dependencies

[tsmaeder]

@JPinkney what are we using the API object for? I've been thinking about remoting the API objects between processes, but I don't think we can, in the general case.

[JPinkney]

The API object has functions for schema things like dynamically adding a schema and modifying a schema that lives in memory

[amisevsk]

As a workaround, I think we should merge https://github.com/eclipse/che-plugin-registry/pull/355 until #15376 is resolved.