Failed to start workspaces using devfile spec v2.1.0

[l0rd]

Describe the bug

When I try to start a workspace using a factory link it fails with "Failed to resolve a devfile."

Che version

Nightly

Steps to reproduce

Deploy Che, on OpenShift, with devworkspace support enabled

$ cat patch.yaml
spec:
  devWorkspace:
    enable: true
$ chectl server:deploy --che-operator-cr-patch-yaml=patch.yaml \
                     -p openshift --no-olm-suggested-namespace \
                     -n workspaces-server

Open a factory link

open ${CHE_URL}/#https://github.com/l0rd/spring-petclinic/                     # <== devfile v2 
open ${CHE_URL}/#https://github.com/l0rd/spring-petclinic/tree/che-happy-path  # <== devfile v1

Runtime

OpenShift 4.7.1

Installation method

$ chectl version
chectl/0.0.20210315-next.19bcb80 darwin-x64 node-v12.21.0

Environment

OpenShift dev cluster

More screenshots

[sleshchenko]

With the nightly Che I have error displayed on Dashboard, and it's the error that Che is not able to find a valid Devfile v1 or v2.

When I try direct link to devfile-v2.yaml (/#https://raw.githubusercontent.com/l0rd/spring-petclinic/master/devfile-v2.yaml) I have another error:

[skabashnyuk]

We only support 1.0.0 and 2.0.0. @l0rd are you sure that 2.1.0 is a valid version?

[l0rd]

The version we should target is 2.1.0

[l0rd]

To be clear, 2.1.0 hasn't been released yet, but that's the devfile/api release that is supposed to include everything required by Che (i.e. 2.0.0 is missing some stuff like cpu limits that are required by Che).

[skabashnyuk]

@l0rd do you want to enable 2.1.0 after official release?

[l0rd]

@skabashnyuk I was expecting that we already supported 2.1.0 (2.1.0-alpha to be precise). In particular because if I am not wrong the DevWorkspace operator that we deploy with Che supports that version of the API, not 2.0.0.

[skabashnyuk]

I was expecting that we already supported 2.1.0

We don't support that version at this moment.
To avoid misunderstanding, can you create an issue explaining what and in which form/version we should support?

[l0rd]

To avoid misunderstanding, can you create an issue explaining what and in which form/version we should support?

You tell me. I would like to support latest version of the spec. DevWorkspace operator supports v 2.1.0-alpha (@sleshchenko keep me honest). Hence it make sense for che-server to be consistent with that.

On the other hand, if aligning Che server and DevWorkspace is hard we can wait the release of 2.1.0 that we should be part of milestone 2.

@sleshchenko @amisevsk @JPinkney what do you think?

[amisevsk]

We've thus far been rolling with whatever the latest schemaVersion for devfile 2.x is. Since 2.x is supposed to be backwards compatible, our check is basically the regex 2\..*.

However, on the Go side, trying to deserialize unknown fields isn't an error -- if DWO supports only 2.0 (no cpuLimit) they'll just be ignored if you throw a 2.1.0 devfile at it. Since we don't have a full 2.1.0 release yet, currently DWO supports devfile features as of commit devfile/api@283b0c5, which is in-line with a 2.1.0-alpha.

[sleshchenko]

our check is basically the regex 2..*.

to be honest, that check is done only when we fetch Devfile via ID or URI(devfile plugin component), but the goal is to rework it to DevWorkspaceTemplate, or both.

DevWorkspace CRD itself does not have schemaVersion at all(since it's devfile metadata which is not part of devfile which is included into devworkspace.spec.template).
DevWorkspace CRD has only the following versions:

• v1alpha1(targets not-released snapshot of devfile v2.0.0 but when it was named v1alpha1);
• v1alpha2(targets some state of devfile v2.1.0, as Angel mentioned, the current state is devfile/api@283b0c5).

Go side just ignore unknown fields, but kubectl does validation and throw an error when unknown field is used, and tell how to skip validation. So, technically dashboard should also warn user if validation is failed.

Kubectl validation details

~/pro/devworkspace-operator main <11 *14 !6 > kc apply -v 7 -f ./samples/flattened_theia-nodejs.yaml             INT 10:59:44
I0317 10:59:47.861929   29992 loader.go:375] Config loaded from file:  /home/sleshche/.kube/config
I0317 10:59:47.862714   29992 round_trippers.go:420] GET https://api.cluster-7c25.7c25.sandbox925.opentlc.com:6443/openapi/v2?timeout=32s
I0317 10:59:47.862732   29992 round_trippers.go:427] Request Headers:
I0317 10:59:47.862740   29992 round_trippers.go:431]     Accept: application/com.github.proto-openapi.spec.v2@v1.0+protobuf
I0317 10:59:47.862748   29992 round_trippers.go:431]     Authorization: Bearer <masked>
I0317 10:59:47.862753   29992 round_trippers.go:431]     User-Agent: kc/v1.19.4 (linux/amd64) kubernetes/d360454
I0317 10:59:48.106081   29992 round_trippers.go:446] Response Status: 200 OK in 243 milliseconds
F0317 10:59:48.430956   29992 helpers.go:115] error: error validating "./samples/flattened_theia-nodejs.yaml": error validating data: ValidationError(DevWorkspace.spec.template.components[3].volume): unknown field "ephemeral" in io.devfile.workspace.v1alpha2.DevWorkspace.spec.template.components.volume; if you choose to ignore these errors, turn validation off with --validate=false

[sleshchenko]

A dedicated issue is created to make Che Server embeds v2.1.0-alpha JSON Schema #19304.

What is plan with 2.1.0-alpha? Is it going to be dropped after v2.1.0 is released?
And then users will have to update their devfiles? Or v2.1.0-alpha will live forever (at least at some git tag) and will be aligned with released 2.1.0?

[l0rd]

Closing this issue. Opening a new one #19322