Check that workspaces start successfully with OCP 4.10 Console samples

[l0rd]

Is your enhancement related to a problem? Please describe

The devfiles included in OCP samples have been updated recently (for v4.10 and v4.9, see the issue for reference).

In particular those devfiles have a parent and include components of type image and of type kubernetes.

Describe the solution you'd like

We need to verify that Che ConsoleLink in an OCP cluster with the latest Che and DevWorkspace starts a workspace successfully.

It doesn't matter if the parent or kubernetes/image components are not supported but source code should be cloned and the IDE should load successfully in the user browser.

Describe alternatives you've considered

After assessing the situation we should evaluate if we need to implement this or not.

Additional context

Reported issues in devfile org:

• nodejs 2.0 and 2.2 devfiles use terminating image under the hood and not usable by Eclipse Che devfile/api#767
• low memory limit for the quarkus devfiles which results in OOM during execution of the 'init-compile' command devfile/api#768
• Commands from Python devfile should be improved devfile/api#777
• Add workingDir attribute into commands definition in Java Spring devfile devfile/api#778

[ibuziuk]

related devworkspace issue - devfile/devworkspace-operator#752

[ibuziuk]

Currently the samples are failing during workspace startup with

[ibuziuk]

Verified against the dogfooding instance (DevWorkspace engine) with the 2.2 samples from https://registry.devfile.io/viewer

• Node.js
  There is a "projects" is not found [1] error displayed on the dashboard, but the workspace is started. However npm install command does not work:

npm ERR! missing script: install

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/theia/.npm/_logs/2022-02-03T12_50_38_639Z-debug.log

Terminal will be reused by tasks. 

Executing commands from the terminal works fine (this works because npm is part of the theia container)

• Python
  There is a "projects" is not found [1] error displayed on the dashboard, but the workspace is started.

No pre-defined commands, executing python commands manually is failing because there is no runtime available in the workspace containers:

• Quarkus
  Workspace is starting without any problems. There are no predefined commands. it is not possible to build / run projects because of the missing java runtime and mvn in the workspace container.

• Spring Boot
  Workspace is starting without any problems. There are no predefined commands. it is not possible to build / run projects because of the missing java runtime and mvn in the workspace container.

@l0rd apart from addressing the "projects" is not found [1] error (funny enough reproducible with Node and Python, but not with Quarkus and Spring Boot) do we need to support runtimes via UDI or it is enough for now to just start a workspace without the possibility of building and running the projects?

[1] #21114

[l0rd]

@l0rd apart from addressing the "projects" is not found [1] error (funny enough reproducible with Node and Python, but not with Quarkus and Spring Boot) do we need to support runtimes via UDI or it is enough for now to just start a workspace without the possibility of building and running the projects?

I think it's ok but what image is used if it's not UDI?

[ibuziuk]

I think it's ok but what image is used if it's not UDI?

It is theia.
Workspace pod would only contain theia, exec and gateway containers for those 2.2 samples

[l0rd]

Oh ok, that's fine I think although at some point we want to run Theia on the dev container too (as for che-code and che-idea IDEs). I don't know if we have an issue for that. cc @benoitf @azatsarynnyy

[benoitf]

the devfile samples have tools container
the one in 4.8/4.9 had https://github.com/devfile-samples/devfile-sample-code-with-quarkus/blob/501e68462dbda71f5bf242879d7cd6ebdfbd8adc/devfile.yaml#L31-L41

and commands were referencing tools component

[benoitf]

so I wanted to know how the check was done ?
from openshift console or trying directly from current state of https://registry.devfile.io/viewer ?

if it's directly using online registry, devfile have parent

for example quarkus has parent
https://registry.devfile.io/viewer/devfiles/Community+java-quarkus

defining the tools component

[ibuziuk]

so I wanted to know how the check was done?

Well, I used the factory link against the dogfooding instance with 2.2 samples for verification e.g. #https://github.com/nodeshift-starters/devfile-sample

for example quarkus has parent
https://registry.devfile.io/viewer/devfiles/Community+java-quarkus

@benoitf my understanding was that this issue is about 2.2 devfiles with kubernetes and image componets available on https://registry.devfile.io/viewer as samples

[ibuziuk]

@benoitf ok, I think I got what you mean - 2.2 sample devfile is referring [1] 2.0 devfile as parent https://registry.devfile.io/devfiles/nodejs and it is expected to be resolved correctly.

I'm not sure if we ever verified this flow cc: @olexii4 @akurinnoy

@benoitf @l0rd is it in general supported flow to have a 2.0 parent for 2.2 devfile? how should this be resolved from the schema perspective?

[1] https://github.com/nodeshift-starters/devfile-sample/blob/main/devfile.yaml#L14-L16
[2] https://registry.devfile.io/devfiles/nodejs

[l0rd]

@benoitf @l0rd is it in general supported flow to have a 2.0 parent for 2.2 devfile? how should this be resolved from the schema perspective?

I don't think that's a bug, the spec allows that, but it would be better to update the parents versions yes.

[ibuziuk]

@l0rd another thing that looks inconsistent is the parent reference.

parent:
  id: nodejs
  registryUrl: "https://registry.devfile.io"

DevWorkspace controller tries to resolve it to https://registry.devfile.io/nodejs which is 404.
The correct link is https://registry.devfile.io/devfiles/nodejs

IMO, registryUrl defined in 2.2 samples should be https://registry.devfile.io/devfiles which would be more straightforward and compatible with DWO. We can handle this case on DWO end of course, but for me this looks like registry / reference issue.

[ibuziuk]

@amisevsk probably we will need to support /devfiles path in DWO - https://github.com/johnmcollier/registry-docs/blob/main/registry-REST-API.adoc#gets-registry-stack-devfile
this is a personal rep with docs, but is linked from https://devfile.io/getting-started#Technology_and_Tools_Builders+Getting_Started

[amisevsk]

There's the doc I was looking for :)

devfile/devworkspace-operator#770

I agree that it makes more sense to have the registryUrl just be https://registry.devfile.io/devfiles but if this is the expected convention then we can accomodate it.

[ibuziuk]

The parent is now processed on both UD and DW end, however, starting the 2.2 nodejs sample is failing with Container runtime has state CrashLoopBackOff for the runtime container:

• Node.js

Some problems with registry.access.redhat.com/ubi8/nodejs-14:latest

2.0 devfile is also failing with the same error # https://registry.devfile.io/devfiles/nodejs

• Python 2.2 seems to be started correctly, however commands do not work OOTB:

ERROR: Could not open requirements file: [Errno 2] No such file or directory: 'requirements.txt'
WARNING: You are using pip version 19.3; however, version 22.0.3 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.

• Quarkus
  thetools container from parent does not exist in workspace pod

• Spring Boot

Commands are not working OOTB:

[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  0.066 s
[INFO] Finished at: 2022-02-0

Also not sure why, but during the first startup of Quarkus and Spring Boot the parent was not proceeded correctly (tools container was missing)

[l0rd]

@ibuziuk thank you. These are bugs that should be reported to github.com/devfile/api, I would suggest to list them as subtasks of devfile/api#681. I had try to list some of the problems here.

[ibuziuk]

Have reported issues related to terminating image (node.js) and low memory limit (quarkus)

• nodejs 2.0 and 2.2 devfiles use terminating image under the hood and not usable by Eclipse Che devfile/api#767
• low memory limit for the quarkus devfiles which results in OOM during execution of the 'init-compile' command devfile/api#768

Regarding the commands execution failures, I'm not sure if this problem is devfile specific since commands seem to be defined correctly.
@svor @azatsarynnyy could you please take a look at the 2.2 basic python [1] and basic spring boot [2] devfiles and clarify why the commands are not working as expected?

[1] https://registry.devfile.io/viewer/devfiles/Community+python-basic
[2] https://registry.devfile.io/viewer/devfiles/Community+java-springboot-basic

[svor]

@ibuziuk
The main problem is that the commands don't have workingDir attribute or it has a wrong value. I've created two issues:

• Commands from Python devfile should be improved devfile/api#777
• Add workingDir attribute into commands definition in Java Spring devfile devfile/api#778

[ibuziuk]

The current state with the 2.2 samples on workspaces.openshift.com (conversion from 2.2 to 1)

• Python [1]
• Node.js [2]
• Quarkus [3]
• Spring Boot [4]

Workspaces are started, the projects are cloned, no pre-defined commands are available (the parent devfiles are not processed, hence the containers with runtimes are not available)

[1] https://workspaces.openshift.com/#https://github.com/devfile-samples/devfile-sample-python-basic
[2] https://workspaces.openshift.com/#https://github.com/nodeshift-starters/devfile-sample
[3] https://workspaces.openshift.com/#https://github.com/devfile-samples/devfile-sample-code-with-quarkus
[4] https://workspaces.openshift.com/#https://github.com/devfile-samples/devfile-sample-java-springboot-basic

[ibuziuk]

Developer Sandbox clusters have been updated to the latest 4.10.3
the state of the 2.2 samples for CRW 2.15.2 #21063 (comment)
Workspaces are started without errors but proper development is not possible

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.