"Restart Workspace from Local Devfile" fails on network restricted clusters

[l0rd]

Describe the bug

Che version

7.71@latest

Steps to reproduce

Deploy Eclipse Che on a cluster that doesn't have access to github.io URLs.
Start a workspace and from VS Code select "restart from local devfile"

Expected behavior

The workspace should be restarted without errors (the internal plugin registry should be used by the devworkspace generator)

[l0rd]

Setting area/editor/vscode as I suspect that's related to how the DevWorkspace generator is invoked (the plugin registry URL is not provided as a parameter)

[RomanNikitenko]

We discussed it recently.
From the discussion I had understanding that generator needs pluginRegistryUrl only to get editor's content.
Che-Code uses the generator to get a new devfile context, we don't need editor's related part.

We pass devfilePath to the generator, pluginRegistryUrl parameter is optional.
Does the generator really require pluginRegistryUrl to regenerate Devfile Context?
If no - I would say it's better to improve generator's logic to use pluginRegistryUrl only when it's really required.

[l0rd]

@RomanNikitenko the simplest looks to update CheCode to pass the pluginRegistryUrl parameter using the CHE_PLUGIN_REGISTRY_INTERNAL_URL env variable if it is set no?
cc @svor @ibuziuk

[svor]

I think it's possible to use CHE_PLUGIN_REGISTRY_INTERNAL_URL env, it should be the simplest way

[RomanNikitenko]

We tried to pass the env variable and users report us some issues with certificates:

workbench.web.main.js:756 Can not restart the workspace from the local devfile: Error: unable to verify the first certificate

so I don't think it's the simplest way...

==========
Update: I'm not sure that CHE_PLUGIN_REGISTRY_INTERNAL_URL url was used when we got that error, maybe CHE_PLUGIN_REGISTRY_URL was used instead...

[l0rd]

Update: I'm not sure that CHE_PLUGIN_REGISTRY_INTERNAL_URL url was used when we got that error, maybe CHE_PLUGIN_REGISTRY_URL was used instead...

We should confirm that. It makes sense that CHE_PLUGIN_REGISTRY_URL doesn't work but CHE_PLUGIN_REGISTRY_INTERNAL_URL should work.

[RomanNikitenko]

There is a pull request with possible solution: che-incubator/che-code#268.
But I'm not able to test it as there is a problem with getting infrastructure with air-gap environment, see CRW-4873.
So, I've stopped progress for this issue.

@musienko-maxim
does QE team has infrastructure for testing it?
if so - it would be helpful to test che-incubator/che-code#268 as a solution for the current issue.

[dmytro-ndp]

@RomanNikitenko : did you try openshift-dev AWS account?
@tolusha could probably help with that.

[RomanNikitenko]

yes, thanks @tolusha and @dmytro-ndp I have an instance for testing

[RomanNikitenko]

I'm not able to reproduce the problem on the air-gap environment that I've got for testing.

I reviewed the corresponding part of the devworkspace-generator library and I see only one use case when pluginRegistryUrl is used:

• to get editor's content when the generator gets editorEntry parameter (please see here).

But starting from June 13 we don't pass editorEntry parameter, the generator gets editorContent parameter instead.

So, I think the issue is not actual anymore.
But, just in case, we can merge my PR:

• it passes CHE_PLUGIN_REGISTRY_INTERNAL_URL to the generator
• it prepares axios instance to use certificates

@l0rd wdyt?

[RomanNikitenko]

I've faced another error for the quay.io/devspaces/code-rhel8:3.7 on the air-gap env:

Upd: I see the same ^ error for the quay.io/devspaces/code-rhel8:3.6 editor.

For those versions of editor https://eclipse-che.github.io/che-plugin-registry/main/v3 is used:

[RomanNikitenko]

Tested also the use case for an instance with proxy.
quay.io/devspaces/code-rhel8:3.7 version of editor has an error:

For the quay.io/devspaces/code-rhel8:3.8 version Restart Workspace from Local Devfile works well.

[RomanNikitenko]

@l0rd
From my point of view the bug is not actual anymore starting from the 3.8, please see #22388 (comment).

Can we somehow confirm that users still face the problem for the 3.8?