Devfile 2.0 parser

[elsony]

/kind user-story

User Story

Add devfile parser support to read devfiles that users the devfile 2.0 specification. Details of devfile 2.0 specification can be found under:
devfile/api#15

Devfile schema link: TBD

Acceptance Criteria

• It should detect the version of devfile based on the apiVersion in devfile to decide if devfile 1.0 parser or devfile 2.0 parser is being used
• It should generate the data model that represents devfile 2.0 model

Links

• Related issue:

/kind user-story
/area devfile

[adisky]

To support Devfile 2.0 following things need to be done in odo.
Add folder 2.0.0 here,
https://github.com/openshift/odo/tree/master/pkg/devfile/parser/data
Add JSON schema for devfile 2.0.0
https://github.com/openshift/odo/tree/master/pkg/devfile/parser/data/2.0.0/devfileJsonSchema200.go
Define devfile 2.0.0 go struct Devfile200
https://github.com/openshift/odo/tree/master/pkg/devfile/parser/data/2.0.0/types.go
Implement the interface DevfileData with Devfile200 struct
https://github.com/openshift/odo/blob/master/pkg/devfile/parser/data/interface.go
https://github.com/openshift/odo/tree/master/pkg/devfile/parser/data/2.0.0/components.go
Add support for version 2.0.0 here
https://github.com/openshift/odo/blob/master/pkg/devfile/parser/data/versions.go

Depending upon devfile structure, we may need to modify the interface and add new methods.

@elsony @kadel If devfile 2.0 json schema is available, please share the link here.

[adisky]

Devfile Json Schema
https://github.com/che-incubator/devworkspace-api/blob/master/schemas/devfile.json

[adisky]

We are unmarshaling here first to get the apiVersion

https://github.com/openshift/odo/blob/d03ed71b484ca9bc672846b9cb7b3dba92b90075/pkg/devfile/parser/context/apiVersion.go#L17

Then again unmarshaling to corresponding apiVersion structure.
https://github.com/openshift/odo/blob/d03ed71b484ca9bc672846b9cb7b3dba92b90075/pkg/devfile/parser/parse.go#L37

[elsony]

@adisky Is there any outlook on the devfile 2.0 parser? There are quite a few items currently depending on that.

[adisky]

@elsony yes i am working on the parser.

few points i would like to get suggestions from team, problem here is Devfile v1 and v2 structures are completely different e.g.

// V1.0.0
type DevfileCommand struct {
	Actions []DevfileCommandAction 
	Attributes Attributes 
	Name string 
	PreviewUrl DevfileCommandPreviewUrl 
}
// V2.0.0
type DevfileCommand struct {
	Composite *Composite 
	Custom *Custom
	Exec *Exec 
	Type string 
	VscodeLaunch *VscodeLaunch 
	VscodeTask *VscodeTask 
}

It is very difficult to come to common types https://github.com/openshift/odo/blob/master/pkg/devfile/parser/data/common/types.go
This common types which is highly specific to v1 are being used everywhere in the adapters code e.g., we can say that adapters code is v1 specific.
https://github.com/openshift/odo/blob/master/pkg/devfile/adapters/common/command.go

I can think of following options to solve it.

1. Common types modified to accomodate v2 types, (cons: maintenance of common structures, lots of checks in adapters about v1 and v2),
2. Seperate code paths from adapters layer .(cons: maintenance of v1 and v2, pros: cleaner snd some duplicated code, v1 v2 check only at one place on CLI layer, removal of v1 is easy)
   https://github.com/openshift/odo/tree/master/pkg/devfile/adapters/v1
   https://github.com/openshift/odo/tree/master/pkg/devfile/adapters/v2

[adisky]

as discussed with @kadel, since it is difficult to map v2 types to common types, for now we are implementing the parser for v2 as separately.

[elsony]

I think it is fine to implement v2 parser separately. I guess the main question is more on how we can easily stage in the v2 functions. Before we have the functions based on v2 implemented enough to replace v1, we'll probably still need to keep the v1 functions around. To do that, the suggested adapter layer approach is probably the cleanest to implement.

[johnmcollier]

@adisky Will your changes include implementing the v2 adapter?

[adisky]

@johnmcollier @elsony Since We were not sure about the adapter approach (creating adapter for each versions), I have added conversion structures from v1 to common, Please check the WIP PR
https://github.com/openshift/odo/pull/3106/files
With this current code should work with devfile v2 also. We can take two approaches from here to use the additional features of v2

1. Modify the common structures, as needed for the new feature, and do not create separate adapter layer. use common structures in adapters
   https://github.com/openshift/odo/blob/master/pkg/devfile/parser/data/common/types.go
2. Create layers for adapters package v1 and v2, and use direct structures of v1 and v2 in adapters package.

[elsony]

The current approach that we have is to covert the devfile v2 to the common structure which is currently based on v1.0. I think it is a simpler way to get the devfile v2 to work with existing code. In a long term, does it makes more sense to have the common structure based on the v2.0 and convert from v1.0 to the common which is based on v2.0? The reason that I am saying that is because by the time that we remove the experimental flag, we'll most likely remove the v1.0 support and only v2.0 devfile will be supported. So using v2.0 as the based for common structure may work better.

[adisky]

The current approach that we have is to covert the devfile v2 to the common structure which is currently based on v1.0. I think it is a simpler way to get the devfile v2 to work with existing code. In a long term, does it makes more sense to have the common structure based on the v2.0 and convert from v1.0 to the common which is based on v2.0? The reason that I am saying that is because by the time that we remove the experimental flag, we'll most likely remove the v1.0 support and only v2.0 devfile will be supported. So using v2.0 as the based for common structure may work better.

yes in the long run, common structures would be based on V2.0. We can modify the common structures one by one, so that it does not break adapters, and also with the features addition based on v2.0.

[elsony]

This approach sounds good to me

[adisky]

closed by #3216