Better plugin mechanism

[l0rd]

We want to replace chePlugin and cheEditor with a new plugin component type that:

• can be specified using the devfile syntax (opposed to 1.0.0 meta.yaml, a devfile-like format)
• is not Che specific, plugins can be specified for odo or even desktop IDEs

Use cases

These are the use cases of devfile plugins (basically Che use cases):

• Reference one or more vs code extensions and the sidecar container that will host them (e.g. the java plugin)
• Reference a container component that is re-used in multiple devfiles/stacks (che-theia is an example)

Proposal

devfile.yaml
---
components:
  - plugin:
      name: 'java language server'
      id: redhat/dependency-analytics/latest  # <= reference plugins published
                                              #    in a plugin registry
      registry: https://plugin-registry.io/
  - plugin:
      name: 'k8s workspace plugin'
      kubernetes:
        namespace: mynamespace
        selector: mykey=myvalue               # <== reference a kubernetes
                                              #     devworkspacetemplate resource
  - plugin:
      name: ...
      uri: https://..../java8-plugin.yaml     # <== reference external raw devfile
      components:                             # <== customise plugin's configuration
        - kubernetes:
            name: ...
            reference: ...
        - container:
            name: vscode-java
            memoryLimit: 2Gi
        - volume:
            name: m2
            size: 2G

java8-plugin.yaml
---
schemaVersion: 2.0.0
metadata:
  publisher: redhat
  name: java8
  version: 0.57.0
  displayName: Language Support for Java 8
  title: Language Support for Java(TM) by Red Hat
  description: Java Linting, Intellisense, (...)
  icon: https://(..)/logo.svg
  repository: https://github.com/redhat-developer/vscode-java
  category: Language
  firstPublicationDate: "2020-02-20"
  pluginType: che-theia-vsx    # <== mandatory for plugins. Valid types
                               #     are che-theia-vsx, che-editor, che-theia-plugin,
                               #     che-theia-extension, generic-service and 
                               #     generic-ui
parent:
  id: redhat/theia-vsx-stack/latest
  components:
    - container:
        name: vsx-installer
        env:
          - name: VSX_LIST
               value: java-dbg.vsix,java.vsix
components:
  - kubernetes:
      name: ...
      reference: ...
  - container:
      image: ...che-sidecar-java
      name: vscode-java
      memoryLimit: "1500Mi"
      volumeMounts:
        - path: "/home/theia/.m2"
          name: m2
  - volume:
      name: m2

Spec Details

• Plugins are defined in separated devfiles
• There are 3 ways to reference a plugin: id, kubernetes, uri. This is consistent with how a parent can be referenced (c.f. Parent Devfiles #25).
• chePlugin is replaced by non Che specific plugin
• There is no editor/plugin distinction (a cheEditor is a plugin with pluginType: che-editor)
• Every plugins configuration can be customised using a kustomize approach. This is consistent with how a parent can be customized.
• Devfile metadata should contains new fields needed to publish it in a registry (the list is shown in the sample)
• Plugins should have a mandatory pluginType metadata that allow tools to figure out if they supported the plugin or not. The list of supported types are che-theia-vsx/che-editor/che-theia-plugin/che-theia-extension/generic-service/generic-ui.

Plugin Registry vs Devfile registry

Plugins are devfile too now. Hence we should rename the devfile registry as stack registry.

As a consequence there will be 2 registries (as before) but name differently:

• the stack registry: a registry of devfiles to be used as parents
• the plugin registry: a registry of devfiles to be used as plugins

Alternatives (rejected for Devfile 2.0.0)

We do not need plugins because we have parents

We may consider to eliminate the plugin concept from the devfile and instead use devfile composition (a.k.a. parents).

registry/uri/kubernetes as different plugins types

For consistency with the Kubernete API spec we may want to use polymorfic plugin type (as we do for components):

  - plugin:
      name: ...
      registryReference:
        id: ...
  - plugin:
      name: ...
      kubernetes:
         ...
  - plugin:
      name: ...
      uriReference:
        uri: ...

instead of

  - plugin:
      name: ...
      id: ...
  - plugin:
      name: ...
      kubernetes:
         ...
  - plugin:
      name: ...
      uri: ...

using parameters in parents

Instead of the simple customisation of a plugin seen above (a la kustomize) we may use parameters to customize some some attributes of a plugin:

parent:
  id: redhat/theia-vsx-stack/latest
  parameters:
    - VSX_LIST: java-dbg.vsix,java.vsix

instead of

parent:
  id: redhat/theia-vsx-template/latest
  components:
    - container:
         name: vsx-installer
         env:
            - name: VSX_LIST
               value: java-dbg.vsix,java.vsix

[l0rd]

A couple of questions that have emerged during today discussion:

• Is the plugin abstraction in a devfile something that is only interesting for Che, or is it interesting for odo as well? If it's for Che only should it be part of the Devfile 2.0.0 specification?
• Is the plugin abstraction something that can be re-used to setup other IDEs workspaces? For instance if a devfile specifies the java plugin can that have a meaning in a VS Code extension context, or in a desktop eclipse context?

[l0rd]

We have reviewed and approved this spec today.

[maxandersen]

question: I assume uri can be relative thus these would resolved both locally on a filesystem or over http/https if loaded there, correct ?

[l0rd]

@maxandersen yes that would be possible. But I would not recommend it. That makes dev workspaces not repeatable. It would work on your machine but not on mine.

[maxandersen]

it would work fine on yours if you have a copy of the devfiles in lets say a git repo. Also makes it easier to develop and do experiments when writing devfile to not have absolute paths as you can do it locally or just move it to some other directory/server if need be.

[l0rd]

that's right @maxandersen, that's an interesting use case we didn't thought about.

[davidfestal]

Implemented