Ignore Che devfile v1

[deboer-tim]

/kind bug

What versions of software are you using?

Operating System:
Mac OS Catalina

Output of odo version:
odo v2.0.1 (a9fff7d)

Actual behavior

If there is a devfile in a project, odo uses it; if there's no devfile then we revert to s2i. However, Che/CRW support devfile v1 and there are lots of sample projects out there that have a v1 devfile in them. If you try to use these with odo they fail.

Expected behavior

If the devfile is a v1 Che devfile, ignore it and revert to the s2i route.

[adisky]

How we will determine if the devfilev1 present in the project repo is from Che/CRW project or from some other project?
or we want to apply this behavior always?

Secondly the s2i component name is to be specified during odo create or s2i component needs to be detected from devfile v1?

[kadel]

How we will determine if the devfilev1 present in the project repo is from Che/CRW project or from some other project?
or we want to apply this behavior always?

Where the Devfile comes from is not important. This behavior should be for all Devfile v1 no matter where they come from.

Secondly the s2i component name is to be specified during odo create or s2i component needs to be detected from devfile v1?

In this situation, odo should behave as there is no devfile. s2i component name can be autodetected or specified by the user.

[adisky]

In this situation, odo should behave as there is no devfile. s2i component name can be autodetected or specified by the user.

Got it its about ignoring devfile.yaml when its version is 1.0.0, odo should consider that no devfile.yaml is present and proceed in the usual way.

[kadel]

@deboer-tim

I'm not sure that this is a good idea.

If the devfile is a v1 Che devfile, ignore it and revert to the s2i route.

If understand correctly what you are proposing is automatically falling back to using s2i.
I'm afraid that this will be confusing for users.
Imagine this.

# git clone project with devfile v1
odo create .....
# odo creates s2i based component

# git clone project with devfile v2
odo create .....
# odo creates devfile component

The problem is that the flow is the same, but the result is completely different, for example, they won't be able to use Kubernetes in the first case (with s2i component).

There is another even more important aspect:
One of the problems that odo team is fighting with is that we have to maintain two code paths; one for s2i one for devfile. As we go deeper into some of the devfile specific features it gets increasingly complicated to maintain s2i portion of the codebase. One of the approaches to solve this problem is to simply use devfile.yml for s2i components. I've tried to describe this solution in #4281.
If we start ignoring devfile v1 we won't be able to do this :-(

[adisky]

If we start ignoring devfile v1 we won't be able to do this :-(

if we implement #4281 and consider this then odo will ignore devfileV1 and generate a devfileV2 considering it as S2I component.

[dharmit]

If the devfile is a v1 Che devfile, ignore it and revert to the s2i route.

If understand correctly what you are proposing is automatically falling back to using s2i.

The way I see it, we're discussing how to move backwards instead of moving forwards when we plan to fallback on s2i. I'm also surprised that we didn't have #4281 around already because I remember us discussing this a bunch of times!

However, Che/CRW support devfile v1 and there are lots of sample projects out there that have a v1 devfile in them. If you try to use these with odo they fail.

How can these projects move to Devfile v2? How can we help? Probably not by code, I'm afraid. I'm assuming it's on their roadmap to move to Devfile v2.

My concern is that while adding Devfile support in odo's experimental mode, we made a conscious decision to support v2 instead of Devfile v1. It took us time and effort and delayed things by more than a bit (correct me if I am wrong here.)

While I understand that we're not discussing going back to Devfile v1 here, it makes me think that why our tools (in this case Che & odo) use different versions of Devfile instead of being in sync at least at the major version level, that is, by using Devfile v 2.y.z.

@kadel @deboer-tim @adisky I am not suggesting that we should not do this. And I am not questioning anyone/anything on Che side of the world. I apologize if my comment sounded that way. My comment is probably tangential to what you folks are discussing and, maybe, not discussing technical aspect of this issue. Just wanted to share my thoughts. And please correct me if/wherever I am wrong.

[maysunfaisal]

IMO from a customer's POV, it would be neat if all the Openshift products aligned, so in that world odo would somehow say devfile v1 is not supported but we can convert it for you to devfile v2, much like the option odo has for convering s2i to devfile v2. But the other argument is, odo started with devfile v2 so its also fair to say, odo will not support devfile v1 at all and err out with a msg and a link explaining how the user can convert to devfile v2 themselves.

Also, +1 to odo just defaulting to devfiles for s2i rather than its own code path.

[deboer-tim]

Yeah, I want to be clear I agree we should not try to support devfile v1 in odo. I also agree that supporting s2i via devfile v2 in #4281 and getting to one codepath sounds very appealing.

Which makes this case pretty difficult. For the next few months until Che moves to devfile v2 + many more months for users to upgrade, there will be projects with devfile v1. Trying to interpret these as v2 in odo will fail, and auto-migrating them to v2 may break Che/CRW users.

If odo utils convert can update w/o breaking compatibility with v1 (likely wouldn't be spec-compliant with either, but have the right content for both?) then that'd be the best option, either now or with #4281. If not, then we need a harder discussion about Che and odo interop during this period.

As much as it is ugly from a user perspective (Tomas' comment above), I still think the better behaviour short term is if odo ignores devfile v1 (treats it like no devfile), ideally with a warning. It is (very unfortunately) trading poor usability outside of Che where we don't expect many users to get into this situation, against extremely poor usability in Che where people are going to see this.

[kadel]

One quick solution to all those problems could be to create a new naming convention for Devfile v2 (devfile2.yaml) so both versions can coexist. But this might create other problems.

Otherwise, it is either what @deboer-tim is proposing here or #4281. But we can't do both.

[kadel]

Now when I think about it there might be a solution, but it will involve a little more coding.

If you call odo create on a directory with existing devfile.yaml and odo detects that it is Devfile v1, it will create Devfile v2 in a file with a different name, like for example devfile2.yaml and save flag to .odo/env/env.yaml that it needs to look for devfile2.yaml and not devfile.yml.
Every other command than will have to first check .odo/env/env.yaml to see if it should work with devfile.yaml or devfile2.yaml

[deboer-tim]

Over time other tools will support devfiles too (even Che itself) and they won't want to find the location via .odo folder. We could create a generic place to store the path, but that's not really better than just picking a different filename. I agree this could cause other problems...

Argh, maybe there's no good interim solution here? What about a hidden flag or temporary experimental setting that the connector sets when within Che that says 'yes, I know there's a devfile, but just use the s2i route'? Basically just give them a path to force s2i-only until Che moves up to devfile 2 itself.

[kadel]

Over time other tools will support devfiles too (even Che itself) and they won't want to find the location via .odo folder. We could create a generic place to store the path, but that's not really better than just picking a different filename. I agree this could cause other problems...

In this case, it would be up to the users to replace devfile.yml with devfile2.yaml once all the tools they are using support Devfile v2. I know that it is not ideal.

Argh, maybe there's no good interim solution here? What about a hidden flag or temporary experimental setting that the connector sets when within Che that says 'yes, I know there's a devfile, but just use the s2i route'? Basically just give them a path to force s2i-only until Che moves up to devfile 2 itself.

This is already there. odo create --s2i will force s2i component even if there is a devfile.
But that will still prevent us from implementing #4281 :-(

[deboer-tim]

After a few other discussions I've suggested we avoid this situation, by essentially sticking on an older pre-devfile odo build for a few months until Che can update to devfile 2. This isn't ideal (and if we get confirmation I'm sorry for the hassle), but it would mean that we can ignore this situation and focus on #4281 and what odo needs w/o distraction.

[sympatheticmoose]

This is already there. odo create --s2i will force s2i component even if there is a devfile.

So here I don't understand what I'm doing wrong... but I cannot get that to work - as shown below

[kadel]

@sympatheticmoose You are not doing anything wrong.
Sadly I didn't realize this before :-( The current behavior is that odo push prefers devfile.yaml over old s2i based components (detected by the presence of .odo/config.yaml), no matter of Devfile version.

This is something that we will have to change. Logic shoudl be:

• if there is .odo/config.yaml and ./devfile.yaml has apiVersion 1.0.0 use .odo/config.yaml (s2i)

[deboer-tim]

Surprisingly, sympathetic moose is not the Canadian in this thread! :)

@kadel, David and I had a chat and agreed to drop this request. We'll leave the version of odo (via the Connector extension) back-levelled until Che can adopt devfile 2. That will avoid this issue and the need to do any temporary settings or workarounds, as well as the potential usability issues you noted above (#4276 (comment)).

If someone really wants to try devfile 2 in Che/CRW in the meantime, we'll be writing a blog that will explain how to update the extension, and note this as a limitation the user will need to avoid.