Skip to content
This repository has been archived by the owner on Aug 2, 2023. It is now read-only.

Provide Operator for Converge on common developer tools - Odo/Devfiles #647

Open
5 tasks
marikaj123 opened this issue Apr 23, 2020 · 2 comments
Open
5 tasks

Comments

@marikaj123
Copy link
Member

marikaj123 commented Apr 23, 2020

Epic: Converge on common developer tools - Odo/Devfiles

@marikaj123 marikaj123 self-assigned this Apr 23, 2020
@marikaj123 marikaj123 transferred this issue from kabanero-io/events-operator Apr 23, 2020
@marikaj123 marikaj123 assigned marikaj123 and unassigned marikaj123 Apr 23, 2020
@marikaj123 marikaj123 assigned kaczyns and unassigned marikaj123 May 4, 2020
@kaczyns kaczyns removed their assignment May 4, 2020
@kaczyns
Copy link
Member

kaczyns commented May 5, 2020

The golang parser for devfiles appears to be here:
https://github.com/openshift/odo/tree/master/pkg/devfile/parser

We're assuming it just parses v1 devfiles now.

@kaczyns
Copy link
Member

kaczyns commented May 12, 2020

I've been looking for a place to organize my thoughts.... this is as good a place as any. Please feel free to correct any technical misunderstandings that you see here. We are only going to speak of v2 devfiles here.

There are two important artifacts (so far) that deal with devfiles - the devfile registry, and the devfile itself. The devfile registry appears to function as the stack-index / stack-hub does. It is a JSON file that contains a list of all the devfiles that are available. For each devfile there is a little bit of information about what that particular stack is, and where it's actual devfile is located. Example:

[
  {
    "displayName": "Maven Java",
    "description": "Upstream Maven and OpenJDK 11",
    "tags": [
      "Java",
      "Maven"
    ],
    "projectType": "maven",
    "language": "java",
    "links": {
      "self": "/devfiles/maven/devfile.yaml"
    }
  },
  {
    "displayName": "NodeJS Express Web Application",
    "description": "Stack with NodeJS 10",
    "tags": [
      "NodeJS",
      "Express",
      "ubi8"
    ],
    "projectType": "nodejs",
    "language": "nodejs",
    "links": {
      "self": "/devfiles/nodejs/devfile.yaml"
    }
  }
]

You will notice that there is a link to the actual devfile, as well as some describing information about what the stack is.

The devfile itself is YAML, I am not going to inline one here because it is quite large. It contains the container images that are used to build and run an application that uses this stack. It looks like it contains some plugin information that might be used by an IDE.

The current proposal (and it's just a proposal) is to have the Kabanero operator generate a devfile registry based on the currently active Stack CR instances, and then host that devfile registry via an external route so that developers can point odo (or whatever needs to read the devfile) at it.

My thoughts and questions include:

  1. The Stack CR instance currently can have multiple versions of a stack. It would seem like the version struct could contain a link to the devfile that goes with it, and that the Kabanero operator could then retrieve that devfile from that URL and use it when hosting the devfile registry (to point back to the devfile).
  2. It's not clear to me whether the information in the devfile registry (ie project type, etc) is important to tooling, or if it's just there to help someone understand what it's pointing at. If it's important to tooling, then there needs to be some way to encode that information into the Stack CR instance so that it can be included in the devfile registry that the Kabanero operator is going to host.
  3. It has been suggested that the Kabanero operator shouldn't need to look at the devile itself, only generate a registry. If that's the case, then it's not clear to me how Kabanero would ever be able to do things like digest checking on the stack container images, since that information is in the devfile yaml, not the devfile registry json.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants