Address Che and odo different interpretations of a 2.x devfile

[l0rd]

Which area this feature is related to?

/area api

The goals of this issues are:

• List the discrepancies between odo and che
• List the changes required to align che and odo

Differences

1. entrypoint of components of type container

odo always overrides the entrypoint or command of a component, Che honors the devfile component entrypoint field.

2. Projects vs starterProjects

Che ignores starterProjects, odo ignores projects:

• Che clones all projects listed in a devfile.
• odo prompts developers to select one of the starterProjects listed in a devfile.

Che automatically infer projects if a devfile.yaml or .devfile.yaml is at the root of a git repository, odo doesn't support devfiles without starterProjects.

3. Components of type Kubernetes

Che extracts the container spec from a Pod or Deployment and adds it in to the "workspace Pod", odo doesn't support components of type kubernetes.

4. Getting started

No devfile, no git repo specified by the user:

• Che has a list of "samples" to start with, each sample source code includes a devfile.
• odo prompt developers to choose a development stack (devfile) and a "starter projects".

No devfile but a git repo is specified by the developer:

• Che uses a default devfile with a container component that uses a Universal Developer Image.
• odo prompts developers to choose a development stack (devfile) from a list

5. Microservice application support

Che runs all services in the same pod (risk of port collision), odo runs each service on a separate pod (requires service binding).

6. Other

• Che supports projects of type zip (for air gap), odo doesn't support starterProjects of type zip?
• odo supports adding services from the catalog, che doesn't have such a mechanism
• Che doesn't support composite commands? odo and apply commands?
• .devfile.yaml support
• Che uses $PROJECTS_ROOT/<project-name>, odo uses $PROJECTS_ROOT (both should use $PROJECT_SOURCE)
• Resource naming differences between Odo & Che. multiple components within the same app have route creation conflict redhat-developer/odo#4957
• DWO library and devfile library differences. should put the migration from DWO library to devfile library on the agenda?

Clarifications to the Devfile spec to avoid the differences

1. entrypoint of components of type container

Tools will need to respect the entrypoint settings. If the entrypoint is not defined, use the default from the image. The containers need to be non-terminating or adding commands and args to make it non-terminating. (Provide example e.g. tail to show).

2. Projects vs starterProjects

Deprecate Projects and only use starterProjects. The devfiles in the community registry will only contain starterProjects definition, no Projects definition.

For starterProjects, if a sample contains a devfile, the tools will keep that devfile and use the devfile that is included in the sample. If a devfile does not exist in the sample, the tools will copy the original devfile that contains the starterProjects definition and use that devfile.

Proposals:

• Remove the definition of Projects and only have starterProjects to provide samples of a given stack. Multiple services development will require the source repo to contain all the services within the same repo.
• Deprecate PROJECT_ROOT variable and tools will use the PROJECT_SOURCE to location the source directory.
• Che may potentially support loading multiple devfiles in the same workspace in the future (investigation needed)

3. Components of type Kubernetes

• odo now supports Kubernetes components as part of the odo link support
• We'll keep the Kubernetes component behaviour, i.e. apply the Kubernetes yaml.
• Che has a use case for using Kubernetes component and needs to inject source (mount) to it. We'll need a new issue to track this requirement.

4. Getting started

• In order to provide better parent adoption, we need to start supporting multiple devfile versions to be stored in a given registry so that the user can refer to specific version of parent devfile. (Support multiple versions of a given stack/sample in a given registry #735)
• Che (and any tools) needs to start prompting the list of starterProjects that the user can clone. Spec needs to explicitly mention that.
• Consider renaming (deprecate) starterProjects to something like samples in the future
• Need to add CR to define the list of available devfile registry (including the ones installed in a given cluster)

5. Microservice application support

• Need to confirm if Che is going to move to single service development model. If we are, this difference does not apply any more.

6. Other

• Che will support Composite command
• odo already supports zip in starterProjects
• Provide an "offline" mode of the registry build to store the starterProjects as zip and package as part of the registry (Devfile registry air gap/offline installation #329)
• Che will investigate supporting adding services and service link support
• Add service definition and service binding to the devfile spec in the future (may need to pick and choose a subset of service definition to support mostly used scenario
• Both odo and Che already supports .devfile.yaml
• "$PROJECT_SOURCE": by default, the working directory is the folder of the project
  • Deprecate PROJECTS_ROOT and move to use PROJECT_SOURCE
  • Tools will set the PROJECT_SOURCE location
• Fix the outer loop spec, currently using PROJECT_ROOT instead of PROJECTS_ROOT, use PROJECT_SOURCE
• Need to come up with a consistent resource naming scheme - need to open a separate item to track
  • With the naming scheme, need to make sure things created in one tool, e.g. che, can be used by another tools, e.g. odo
• For ODC, need to change to use Kubernetes components for outer loop build to provide consistent behaviour
• Should merge the DWO library and devfile library
  • Should odo (and other tools) optionally uses the DWO if it exists to make it consistent?

[amisevsk]

A few additional comments from the DWO side of things:

1. entrypoint of components of type container

We don't override the entrypoint because containers generally need to do some setup on startup and overriding the entrypoint would break that. E.g. current Che devfiles use this entrypoint.sh, and in general something like the OpenShift guidelines is necessary.

Container entrypoints can be manually overriden via command and args in the container component spec.

3. Components of type Kubernetes

Currently, DWO also ignores kubernetes and openshift-type components.

[kadel]

Currently, DWO also ignores kubernetes and openshift-type components.

Supports kubernetes components, and uses it for storing definitions (CRs) for operator backed services.

[kadel]

• Che uses $PROJECTS_ROOT/<project-name>, odo uses $PROJECTS_ROOT (both should use $PROJECT_SOURCE)

working on devfile/registry#85