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

[marikaj123]

Epic: Converge on common developer tools - Odo/Devfiles

• Put the stack controller into odo mode or devfile mode Stack controller appsody/odo mode #747
• Process a Stack CR instance that contains links to a devfile Add devfile urls to the Stack CRD #748
• Serve a dynamic v2 devfile registry representing the currently active Stack CRs Host a devfile registry based on the currently active Stack CR instances #749
• Pull pipelines from Kab CR instance if not defined in the Stack CR Stack controller can default to pipelines in Kab CR instance for Odo #762
• Add a stack level pipelines definition to the Stack CR Add a field for default pipelines in a Stack CR instance #763

[kaczyns]

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]

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.