Odo: Project devfile deleted

[jeffmaury]

/kind bug

When a component is created from a project that is managed on source control and has its own devfile, odo create --devfile devfile.yaml is the way to create the component. But when the component is deleted, the devfile is also deleted.

What versions of software are you using?

Operating System:
Win10Pro

Output of odo version:

odo v2.0.0 (6fbb9d9bf)

Server: https://172.16.0.10:8443
Kubernetes: v1.11.0+d4cacc0

How did you run odo exactly?

• odo create --devfile devfile.yaml
• odo delete -f --all

Actual behavior

devfile.yaml is deleted

Expected behavior

devfile.yaml should not be deleted

Any logs, error output, etc?

[mohammedzee1000]

Like I said on chat. I do not think odo should handle deletion of devfile at all. You can in the message that deletion of devfile is the users respondsibility. It is a simple rm -rf anyway.

[dharmit]

IMO, we should delete devfile only if it's not tracked by the VCS.

[mohammedzee1000]

I see no point in taking on the additional difficulty of detecting VCS tracking. If the user does not want the devfile, he can remove it

[adisky]

IMO, we should delete devfile only if it's not tracked by the VCS.

Detecting the VCS will introduce complexity, if we know it would always be git then it is easier to implement
overall we have three options to handle

• Delete devfile.yaml if it is not tracked by VCS
• Do not delete devfile.yaml for any case
• Save devfile.yaml created by odo with some different name (e.g. devfile-odo.yaml, .devfile.yaml etc), and delete the one created by odo.

[dgolovin]

Why not to put `--devfile path/to/devfile.yaml' to env.yaml as a devfile=path/to/devfile.yaml? That would be consistent with other settings saved in env.yaml and can be used to detect if devfile.yaml is provided by user or taken form registry.

ComponentSettings:
  Name: python-app
  Project: p4
  AppName: app
  RunMode: run
  Devfile: path/to/devfile.yaml

Just an idea.

[kadel]

@dgolovin

Why not to put `--devfile path/to/devfile.yaml' to env.yaml as a devfile=path/to/devfile.yaml? That would be consistent with other settings saved in env.yaml and can be used to detect if devfile.yaml is provided by user or taken form registry.

ComponentSettings:
  Name: python-app
  Project: p4
  AppName: app
  RunMode: run
  Devfile: path/to/devfile.yaml

Just an idea.

How would this help. Assuption is that devfile.yaml is always in the root of your source code.
For example, if you do odo create --devfile /path/to/devfile.yml it will copy /path/to/devfile.yml to the current directory.
Then if you run odo delete --all it will delete the devfile from the current director, and it will keep the one in /path/to/devfile.yml

How did you run odo exactly?

• odo create --devfile devfile.yaml
• odo delete -f --all

Actual behavior

devfile.yaml is deleted

This is the expected behavior.

odo delete - deletes all resources from the cluster. This is an inverse function to odo push
odo delete --all - deletes all resources from the cluster and all local files created by odo. This is an inverse function to odo create and odo push. If we don't delete devfile.yml then it will be weird, as this file gets usually generated by odo create but now the user would have to delete it separately.

I agree that odo create --devfile devfile.yml is a little bit weird command, because it is using the devfile from the current directory to setup the odo component in the current directory.
We might need to look into this command. Maybe this command should error out, not sure how much sense it makes to do this if there already is devfile.yml in the current directory.
If you run odo push in a directory with devfile.yml without .odo, it will bootstrap new .odo. Other commands should probably work the same way. So if I do odo url create in a directory with devfile.yml but without .odo it will bootstrap the new default .odo directory. This will eliminate the need for odo create --devfile devfile.yml.

[girishramnani]

My suggestion is to add a flag UserCreatedDevfile: true If we find the devfile already present on odo create or push.

Then we decide to not delete the devfile when someone does odo delete —all.

One observation is that odo delete —all fails if someone tries to run it in a directory that just has a devfile and no env.yaml. This behaviour helps in the current implementation.

[kadel]

My suggestion is to add a flag UserCreatedDevfile: true If we find the devfile already present on odo create or push.

You mean saving UserCreatedDevfile: true in .odo/env.yml right? That should work, we can go with this.

But we need to think about backward compatibility. If someone has an existing devfile component odo should not error out.
So I assume that the default value for UserCreatedDevfile is going to be false.

[dgolovin]

That is a good catch, for old project created with previous odo version devfile.yaml should be treated as user provided and should not be deleted.
I personally would be fine if defvile.yaml is just not being deleted with odo delete -all.

[dharmit]

I personally would be fine if defvile.yaml is just not being deleted with odo delete -all.

Nitpicking here maybe. odo delete --all asks for a confirmation before touching devfile anyway:

$ odo delete --all
? Are you sure you want to delete the devfile component: node-todo? Yes

Gathering information for component node-todo
 ✗  Checking status for component [10ms]
 ⚠  pod not found for the selector: component=node-todo

Deleting local config
? Are you sure you want to delete env folder? Yes
 ✓  Successfully deleted env file
? Are you sure you want to delete devfile.yaml? No
 ✗  Aborting deletion of devfile.yaml file

$ ls -a
.  ..  app  config  .git  .openshift  public  devfile.yaml  .gitignore  license  package.json  README_es.md  README.md  server.js

If odo delete --all is what you use, I don't think there's any issue to be fixed.

[jeffmaury]

Solution that requires interactive mode is not compatible with IDE integrations

[girishramnani]

My suggestion is to add a flag UserCreatedDevfile: true If we find the devfile already present on odo create or push.

You mean saving UserCreatedDevfile: true in .odo/env.yml right? That should work, we can go with this.

But we need to think about backward compatibility. If someone has an existing devfile component odo should not error out.
So I assume that the default value for UserCreatedDevfile is going to be false.

Agreed

[kadel]

That is a good catch, for old project created with previous odo version devfile.yaml should be treated as user provided and should not be deleted

I would argue that it needs to be the other way around.
The assumption is that most people will have devfile created by odo.

Also with @girishramnani proposal UserCreatedDevfile means that user-provided devfile (it was not created by odo).

UserCreatedDevfile: true - odo doesn't delete devfile
UserCreatedDevfile: false - odo deletes devfile.

Default is false.

I personally would be fine if defvile.yaml is just not being deleted with odo delete -all.

That is not going to work, as command line users wouldn't have a way to delete devfile using odo.
If there is a create that creates devfile there needs to be a delete that deletes devfile.
And saying that they can always delete it manually is not a solution then we can say that we don't need the delete command at all.

[kadel]

It should be like this:

• UserCreatedDevfile: true will be set in only in the following commands:
  
  
  
  • odo create --devfile devfile.yml
  
  
  • odo push only if .odo/env.yml doesn't exists yet.
  
  

Note that odo create --devfile /some/path/devfile.yml will NOT set UserCreatedDevfile: true.
This is because this command is the same odo would download devfile from the devfile registry.
The devfile will still exist in the original path.

• odo delete --all checks for UserCreatedDevfile, if it is true it skips devfile.yml deletion.

[mohitsuman]

So this basically means if the devfile is in the root of the workspace, it will set UserCreatedDevfile: true after odo create ?

Does all Che workspaces follow this convention to have devfile in the root scope. Just want to get it confirmed ?

@kadel @deboer-tim

Note that odo create --devfile /some/path/devfile.yml will NOT set UserCreatedDevfile: true.
This is because this command is the same odo would download devfile from the devfile registry.
The devfile will still exist in the original path.

[deboer-tim]

FWIW, I'm not a fan of solutions that save info on one file in another file. IMHO that leaves open other problems when the two get out of sync, e.g. when working in a team with multiple changesets; when one gets checked into git and not the other; etc. I'd lean towards just not deleting the devfile - but I don't know the background or other reasons for this behaviour so I'll defer to the odo team.

Does all Che workspaces follow this convention to have devfile in the root scope. Just want to get it confirmed ?

Not completely - e.g. Che can have a 'workspace root' devfile that's not in one of the workspace projects, or you can use a factory to create a workspace from a single repo/project that contains a devfile. The first case doesn't matter though (odo and Che are already looking at different devfiles), and this solves the second case.

[kadel]

So this basically means if the devfile is in the root of the workspace, it will set UserCreatedDevfile: true after odo create ?

@mohitsuman, Not exactly. Mi Odo assumes that Devfile is always in the root of the source code, you don't really have other option.
UserCreatedDevfile: true will be set only when odo detects Devfile that was not created by odo.

FWIW, I'm not a fan of solutions that save info on one file in another file. IMHO that leaves open other problems when the two get out of sync, e.g. when working in a team with multiple changesets; when one gets checked into git and not the other; etc. I'd lean towards just not deleting the devfile - but I don't know the background or other reasons for this behaviour so I'll defer to the odo team.

@deboer-tim, I agree that it might not be ideal solution.
But env.yaml should never bechecked into git. Odo even adds that file to .gitignore.
I think that it would be pretty weird if odo delete wouldn't delete all files that odo create created.
If we always skip Devfile deletion I would expect that the first issue that we get is why Odo is not cleaning after itself.
But if there is a need for this maybe we could also introduce something like odo delete --all --keep-devfile

[girishramnani]

taking this on priority

[girishramnani]

PR is up for this @dgolovin @jeffmaury https://github.com/openshift/odo/pull/4353 - need to write tests but else its functional if you want to test it

[girishramnani]

sample output

odo delete -f --all

Gathering information for component bhas
 ✗  Checking status for component [220ms]
 ⚠  pod not found for the selector: component=bhas

Deleting local config
 ✓  Successfully deleted env file
Didn't delete the devfile as it was user provided

[girishramnani]

Tests added