Odo: Erasing a local devfile is not enough to reset odo

[metacosm]

/kind bug

What versions of software are you using?

Operating System: macOS 10.15.4

Output of odo version:
odo v1.2.0 (e1232ad1a)

Server:
Kubernetes: v1.11.0+d4cacc0

How did you run odo exactly?

1. odo component create maven
2. Realize that I actually wanted another component type
3. odo component create java-spring-boot
4. Get an error: ✗ This directory already contains a devfile.yaml, please delete it and run the component creation command again
5. So follow the instructions and delete devfile.yaml
6. odo component create java-spring-boot:

Experimental mode is enabled, use at your own risk

Validation
 ✓  Checking devfile compatibility [14ms]
 ✗  Validating devfile component [114030ns]
 ✗  This workspace directory already contains a devfile component

Actual behavior

See above.

Expected behavior

Be able to create my component the second time around without issue. At least, provide a better error message that would allow a user to fix the issue.

Any logs, error output, etc?

[girishramnani]

4. Get an error: ✗ This directory already contains a devfile.yaml, please delete it and run the component creation command again

can you try odo delete at this stage? and if that works then we just need to reword the error message

[kadel]

The workaround is rm -r .odo devfile.yaml.

This is a pretty bad experience we need to do something with odo delete command

[kadel]

/priority high

[girishramnani]

Doesn’t odo delete actually remove .odo folder?

[kadel]

Doesn’t odo delete actually remove .odo folder?

nope, and also odo delete doesn't work when the component was not pushed :-(

[kadel]

TODO:

• [ ] update the error message ✗ This directory already contains a devfile.yaml, please delete it and run the component creation command again to say ✗ This directory already contains a devfile component. You can delete it using odo delete -a command and run the component creation command again`
• [ ] odo delete should work even if the component was not pushed, and it should delete only .env folder
• [ ] odo delete -a should work even if the component was not pushed, and it should delete both .env folder and devfile.yaml
• [ ] update help message for odo delete command

[mik-dass]

odo delete --all removes the .odo folder even when the component is not pushed.

[mrinaldas@localhost che-nodejs]$ odo create nodejs
Experimental mode is enabled, use at your own risk

Validation
 ✓  Checking devfile compatibility [108020ns]
 ✓  Validating devfile component [393139ns]

Please use `odo push` command to create the component with source deployed
[mrinaldas@localhost che-nodejs]$ odo delete -f --all
I0507 21:40:11.605355   28131 cert_rotation.go:137] Starting client certificate rotation controller
 ✗  Deleting devfile component nodejs [1ms]
 ✗  error occurred while deleting component, cause: the component nodejs doesn't exist on the cluster
 ✓  Successfully deleted env file
[mrinaldas@localhost che-nodejs]$ ls -a
.   app           .git        LICENSE       package.json       README.md
..  devfile.yaml  .gitignore  node_modules  package-lock.json  .vscode

In the issue we decided not to remove the devfile.yaml https://github.com/openshift/odo/issues/2591#issuecomment-602685412. Maybe we can update odo delete all to delete the devfile too?

+1 for updating the error message though.

[metacosm]

odo delete shouldn't cause an error if the component isn't pushed. At worse, it should be a warning but it shouldn't be an error to not have to erase anything on the cluster :)

[metacosm]

Also, a user shouldn't have to care about an env directory that they never asked to create: this is an internal mechanism to odo that shouldn't surface in user operations, in my opinion.

[elsony]

* `odo delete -a ` should work even if the component was not pushed, and it should delete both `.env` folder and devfile.yaml

@kadel I am not sure if we should delete the devfile.yaml for the user as part of the odo delete -a command or should we require the user to manually delete the devfile.yaml. Consider the scenario that developer A has developed an app and check into git together with a customized devfile.yaml. Then, developer B clone that app git repo and use odo to continue to do the development. After developer B is done with the component, if developer B do odo delete -a, we'll be removing the devfile.yaml that is not even created by odo. Should we consider the devfile.yaml as part of the application resource and let the user handle the lifecycle of that?

[dharmit]

I think that odo create and odo delete have different definitions to determine if the pwd is a component directory. I opened #3155 for the same. I think this issue is also pointing to the same.

[maysunfaisal]

odo delete -a does not need component to be present to delete the .ododir. But agree that it should be not throw an err and maybe just a warning to say no component was present and proceed to prompt if env should be deleted.

I also think we should not delete the devfile.yaml with odo delete -a since we can create a component odo create nodejs for example, with an existing devfile.yaml in current dir.

If we really want to delete devfile.yaml with odo delete -a, the alternative would be to prompt a question and ask if the devfile.yaml should be deleted.

I can take a look at this
/assign

[kadel]

I also think we should not delete the devfile.yaml with odo delete -a since we can create a component odo create nodejs for example, with an existing devfile.yaml in current dir.

If we really want to delete devfile.yaml with odo delete -a, the alternative would be to prompt a question and ask if the devfile.yaml should be deleted.

Agreed with the second part, odo delete --all should definitely prompt for confirmation, the same as it is currently asking when running odo delete. Only when --force flag is provided the prompt should be skipped.

@kadel I am not sure if we should delete the devfile.yaml for the user as part of the odo delete -a command or should we require the user to manually delete the devfile.yaml. Consider the scenario that developer A has developed an app and check into git together with a customized devfile.yaml. Then, developer B clone that app git repo and use odo to continue to do the development. After developer B is done with the component, if developer B do odo delete -a, we'll be removing the devfile.yaml that is not even created by odo. Should we consider the devfile.yaml as part of the application resource and let the user handle the lifecycle of that?

Hmm, that also makes sense.

But what about this scenario:

• I create new odo component odo create
• I realized that I wanted to do something else
• I run odo delete --all with the assumption that it will delete everything that odo created after all the flag is called all (but in this case it will keep devfile.yaml)
• I run odo create again and it fails :-(

I think that if we are clear about what the odo delete -a does it should be ok, after all, it is not a default delete strategy users will need to provide additional flag, and they will be asked to confirm.
If odo is creating devfile with odo create there should be also a variation of odo delete command to completely clean what odo created.

What about this?

• odo delete
  
  
  
  • should delete what was created in the cluster and keep .odo and devfile.yaml in place
  
  
  • if the component was not pushed yet (nothing was created in the cluster) it should just print information that there is nothing in the cluster. No error should be thrown.
  
  
  • should ask the user for confirmation unless executed with -f flag
  
  
  • the output should contain information that this is just deleting resources from the cluster
  
  
• odo delete --all
  
  
  
  • should delete everything form cluster as odo delete does
  
  
  • in addition to deleting resources from the cluster, it should also delete .odo and devfile.yaml
  
  
  • should ask the user for confirmation unless executed with -f flag
  
  
  • confirmation will have three stages.
    
    
    
    
    
    • "_Do you want to delete all resources related to this component from the cluster? (Y/n)_"
    
    
    
    • "_Do you want to delete local configuration in .odo directory? (Y/n)_"
    
    
    
    • "_Do you want to delete devfile.yaml from the current directory? (Y/n)_"
    
    
    
  
  

This would make odo delete is an inversion of odo push and odo delete --all inversion of odo create; odo push and the user will always have a choice to decide what to delete.

What do you think?

[metacosm]

All of this makes sense :)
However, reading through the different scenarios makes me think that odo should keep track of the files it created and should only be able to delete these files and nothing else. It doesn't seem right that odo should be able to delete files it knows nothing about.
Which brings me to another usage question: is it expected that users will need to edit devfiles often? It seems to me that they should be implementation details that shouldn't really be touched all that often by users.

[elsony]

This would make odo delete is an inversion of odo push and odo delete --all inversion of odo create; odo push and the user will always have a choice to decide what to delete.

This proposal sounds good to me. We have an explicit prompt for devfile.yam removal which will address my main concern.

Which brings me to another usage question: is it expected that users will need to edit devfiles often? It seems to me that they should be implementation details that shouldn't really be touched all that often by users.

I think the key point is not really on whether they touch it often; it is whether we expect user to change it or not. We do expect user to change it since there may be specific changes that they need on the devfile to fit their specific application, e.g. I need to have this env variable setup on my container, I use my own custom image for my container in order for my app to work, etc.. If we try to track what is created by odo or not, I am worry that we'll start to complicate it too much. I'd prefer the more simple approach on prompting that @kadel suggested.

[metacosm]

Which brings me to another usage question: is it expected that users will need to edit devfiles often? It seems to me that they should be implementation details that shouldn't really be touched all that often by users.

I think the key point is not really on whether they touch it often; it is whether we expect user to change it or not. We do expect user to change it since there may be specific changes that they need on the devfile to fit their specific application, e.g. I need to have this env variable setup on my container, I use my own custom image for my container in order for my app to work, etc.. If we try to track what is created by odo or not, I am worry that we'll start to complicate it too much. I'd prefer the more simple approach on prompting that @kadel suggested.

Wouldn't that be done by extending the devfile instead of modifying it directly?

[maysunfaisal]

Wouldn't that be done by extending the devfile instead of modifying it directly?

@metacosm Wdym by extending devfile instead of modifying it? 🤔

[metacosm]

Wouldn't that be done by extending the devfile instead of modifying it directly?

@metacosm Wdym by extending devfile instead of modifying it? 🤔

@maysunfaisal Using devfile 2, wouldn't one extend a devfile instead of checking it out and then changing it? I.e. if I want to change some parameters in a devfile, would I be better served extending that devfile and overriding the value I want instead of creating a whole new copy of the devfile (which I then would need to maintain) just to change one parameter?