Allow to specify in a plugin meta link to a che-plugin.yaml when having a separate archive is not needed

[garagatyi]

Issue problem:
Upstream issue eclipse-che/che#11814
Now Theia meta.yaml points to an archive with che-plugin.yaml that contains Theia sidecar definition. We have to use a broker to evaluate this config. Instead of that, we could point directly to a che-plugin.yaml and let Che master download this config without brokering at all.

Red Hat Che version:

version: (help/about menu)

• I can reproduce it on latest official image

Reproduction Steps:

Describe how to reproduce the problem

Runtime:

runtime used:

• minishift (include output of minishift version)
• OpenShift.io
• Openshift Container Platform (include output of oc version)
• k8s (include output of kubectl version)

[amisevsk]

After discussion with @garagatyi today, we decided to put off working on this specific issue for a few reasons:

• It's not clear how this would benefit us, as some brokering would have to happen in any case. This could be avoided but would require more significant changes to registry/broker/etc.
  • It's maybe not a good idea to spend time doing this work as some registry/broker stuff is still in flux and so could change requirements
• It potentially makes more sense to do these changes in the plugin registry (e.g. allow Che server to request sidecar definitions from registry directly, allowing this data to be cached). This change would invalidate most work done on this issue.
• It's not clear how this work would interact with other brokers (e.g. theia and vscode) so work should be put off until the architecture there settles a little more. E.g. vscode broker would be incompatible with some changes.
• The potential benefit for us running Che is speeding up workspace start by ~5 seconds, but this is only in the near-term, as these changes would need to be reworked in the coming weeks anyways.
  • To actually gain these ~5 seconds, it would be required to modify the registry to provide yaml files for all plugins and editors. Otherwise the plugin broker will run anyways and there's no speedup. This is a lot of work for what is kind of a temporary hack.

@garagatyi let me know if I missed anything here.

@ibuziuk WDYT? Should we close this issue for now, and create a new issue when the task required is more well-defined or leave it in the backlog?

[garagatyi]

👍

[ibuziuk]

@amisevsk thanks for details. Yeah, for me it makes sense to stop working on this issue.
@garagatyi wdyt, should we close it now together with the upstream issue to avoid misleading since it looks like we are not ready for those changes due to upcoming plugin brokering changes [1]?

[1] eclipse-che/che#11980

[garagatyi]

After discussion inside of OSIO-Che team we decided to close this issue since brokering process should be redesigned as part of this epic.