ODO doesn't support Devfile schema v.2.2.2

[vrubezhny]

/kind bug

ODO fails to initialize a component when Devfile schema v.2.2.2 is used.

What versions of software are you using?

Operating System:

Fedora Linux 6.8.7-100.fc38.x86_64

... but the issue is not OS/Arch dependent

Output of odo version:

$ odo version odo v3.15.0 (10b5e8a8f)

Server: https://127.0.0.1:42801 Kubernetes: v1.27.3 Podman Client: 4.9.4

How did you run odo exactly?

$ odo init --name=component1 --devfile=nodejs --starter=nodejs-starter

Actual behavior

ODO reports error: ✗ unable to parse devfile: failed to populateAndParseDevfile: unable to find schema for version "2.2.2". The parser supports devfile schema for version 2.0.0, 2.1.0, 2.2.0, v1alpha2

Expected behavior

The ODO init command should be executed successfully

Any logs, error output, etc?

$ mkdir starter
$ cd starter/
$ odo init --name=component1 --devfile=nodejs --starter=nodejs-starter
  __
 /  \__     Initializing a new component
 \__/  \    
 /  \__/    odo version: v3.15.0 (10b5e8a8f)
 \__/

 ✓  Downloading devfile "nodejs" [1s]
 ✗  unable to parse devfile: failed to populateAndParseDevfile: unable to find schema for version "2.2.2". The parser supports devfile schema for version 2.0.0, 2.1.0, 2.2.0, v1alpha2
the command failed, the devfile has been removed from current directory

[rm3l]

Hi @vrubezhny ,

I can see that this issue is fixed in the main branch (6d83e4043) of odo, certainly because the Devfile library was updated in https://github.com/redhat-developer/odo/pull/7240.

$ odo init --name=component1 --devfile=nodejs --starter=nodejs-starter         
  __
 /  \__     Initializing a new component
 \__/  \    
 /  \__/    odo version: v3.15.0 (6d83e4043)
 \__/

 ✓  Downloading devfile "nodejs" [986ms]
 ✓  Downloading starter project "nodejs-starter" [417ms]

Your new component 'component1' is ready in the current directory.
To start editing your component, use 'odo dev' and open this folder in your favorite IDE.
Changes will be directly reflected on the cluster.

The latest release of odo is a bit "old", and there is currently no plan to release a newer version (unless there are critical or security issues to fix of course).

Would it make sense for you to use nightly builds of odo instead? See https://odo.dev/docs/overview/installation#nightly-builds They are quite stable and AFAICT, the diff between 3.15 and the main branch is mostly around dependency updates and fixing tests: https://github.com/redhat-developer/odo/compare/v3.15.0...main

[vrubezhny]

@rm3l Thanks! We'll consider using the nightly builds for 'odo'. This definitely could be a solution at the moment.

[vrubezhny]

The problem with using the nightly builds is that the download links are "static" - so we're not able to save sha256 for a binary archive and then verify the archive downloaded much later by such a "static" link against the saved sha256 value...

For the releases we're downloading "an approved" binary version and usually an archive for each version has its unique sha256 which never changes, so for a released version we can download the same archive later and verify it against the sha256 saved to that version. With "static" download links it's not possible (also, I believe, the track of nightly builds isn't kept, so with a time passed we'll be downloading some other archive using the same URL).

[vrubezhny]

@rm3l Thanks a lot for https://github.com/redhat-developer/odo/commit/3d77fe9d2b65311ebf064bc75cf0d17320114640! :+1:

[rm3l]

Hey @vrubezhny ! You noticed before I pinged you :-) Yes, this is a quick experiment to see if it would help in the future for similar situations. I plan anyway to create a 3.16.0 release today.

[vrubezhny]

Hey @vrubezhny ! You noticed before I pinged you :-) Yes, this is a quick experiment to see if it would help in the future for similar situations. I plan anyway to create a 3.16.0 release today.

This should help us a lot in case the nightly build archives and according *.sha256 files that has commit ID in their names history is kept in time as we need to have a possibility to save the archives URLs and their sha checksums for the archives, and then later, when we need to download the binary we were able to verify it against the saved sha checksum. If this workflow works - it'll be great help for us as we won't need to ask ODO team to perform a new release every time the Devfile schema version is updated or anything similar happens in the future.

Thanks!

[rm3l]

@vrubezhny So I tried to create a 3.16.0 release yesterday but hit a roadblock with the RH internal build systems, which, I think, would require a few additional changes.. As I didn't plan to spend too much time on those build issues, I would suggest that you move forward with the nightly binaries (pinned to a commit ID). Let me know if you run into any issues with the nightly binaries. Thanks.

[rm3l]

@vrubezhny FYI, I was keeping an eye on the internal issues that were blocking a new release, and they have all been fixed recently. A new release of odo v3.16.1 is now available: https://developers.redhat.com/content-gateway/rest/mirror/pub/openshift-v4/clients/odo/v3.16.1 🎉

Closing this issue now, but feel free to reopen if the issue still persists.

/close

[openshift-ci[bot]]

@rm3l: Closing this issue.

In response to [this](https://github.com/redhat-developer/odo/issues/7244#issuecomment-2189392178): >@vrubezhny FYI, I was keeping an eye on the internal issues that were blocking a new release, and they have all been fixed recently. >A new release of `odo` v3.16.1 is now available: https://developers.redhat.com/content-gateway/rest/mirror/pub/openshift-v4/clients/odo/v3.16.1 🎉 > >Closing this issue now, but feel free to reopen if the issue still persists. > >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes-sigs/prow](https://github.com/kubernetes-sigs/prow/issues/new?title=Prow%20issue:) repository.