odo component delete doesn't actually delete the component

[jankleinert]

[kind/bug]

What versions of software are you using?

• Operating System: macOS
• Output of odo version: v1.0.0-beta1

How did you run odo exactly?

odo create nodejs backend
odo push
odo url create backend --port 8080
odo push
odo component delete backend (y, to delete URL)

See output below.

Actual behavior

As you can see from the output below, running odo component delete backend says it's deleted, but the config is still there and I cannot create a new component in that directory.

$  odo component get
The current component is: backend
 $  cat .odo/config.yaml
kind: LocalConfig
apiversion: odo.openshift.io/v1alpha1
ComponentSettings:
  Type: nodejs
  SourceLocation: ./
  SourceType: local
  Application: app
  Project: odo-workshop-h6djc
  Name: backend
  Url:
  - Name: backend
    Port: 8080
 $ odo component delete backend
This component has following urls that will be deleted with component
URL named backend with host backend-app-odo-workshop-h6djc.apps.jkleinert-e293.openshiftworkshop.com h
aving protocol http at port 8080
? Are you sure you want to delete backend from app? Yes
 ✓  Deleting component backend
 ✓  Component backend from application app has been deleted
$ odo component get
The current component is: backend
 $ cat .odo/config.yaml
kind: LocalConfig
apiversion: odo.openshift.io/v1alpha1
ComponentSettings:
  Type: nodejs
  SourceLocation: ./
  SourceType: local
  Application: app
  Project: odo-workshop-h6djc
  Name: backend
  Url:
  - Name: backend
    Port: 8080
  $  odo create nodejs backend2
 ✗  this directory already contains a component

Expected behavior

I expected odo component delete to remove the component configuration. I cannot find a way to do that, meaning I'd have to delete .odo/config.yaml if I want to get rid of my component and create a new one.

Any logs, error output, etc?

[cdrage]

Yeah, I ran into the exact same issue too, deleting a project also does the same problem (leave the configuration file there... or doesn't allow overriding)

Any chance you can pick this up @girishramnani ?

[jorgemoralespou]

I think this should be the default behavior, and to delete the components configuration files locally we should do one of either:

• odo delete --all (this or some other similar flag makes sense to not introduce a new command)
• odo destroy (this makes sense since odo create is the action to create this)

I think we should see which option is best, but not delete local configuration.

[jankleinert]

If the default, intended behavior is to delete it from the cluster but not local config (is that what is happening?), then the help text/description of the command should make that very clear.

…

On Fri, Apr 26, 2019 at 3:51 PM Jorge Morales Pou ***@***.***> wrote: I think this should be the default behavior, and to delete the components configuration files locally we should do one of either: - odo delete --all (this or some other similar flag makes sense to not introduce a new command) - odo destroy (this makes sense since odo create is the action to create this) I think we should see which option is best, but not delete local configuration. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1654 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAE7DUCWEAGLAOTTB5GNX6TPSNMLZANCNFSM4HIV3I2A> .

[girishramnani]

@cdrage sure I can pick this up
/assign girishramnani

[girishramnani]

I think this should be the default behavior, and to delete the components configuration files locally we should do one of either:

• odo delete --all (this or some other similar flag makes sense to not introduce a new command)
• odo destroy (this makes sense since odo create is the action to create this)

I think we should see which option is best, but not delete local configuration.

I would prefer the odo delete --all because we have odo create for creation but will end up with two kinds of removal i.e. odo delete and odo destroy which would be

• confusing
• not symmetric

so my vote is on odo delete --all.
thoughts @kadel?

[kadel]

How about changing odo delete to delete both (local config and from cluster) and odo destroy would just delete stuff from the cluster? Wouldn't that make more sense?

[jorgemoralespou]

How about changing odo delete to delete both (local config and from cluster) and odo destroy would just delete stuff from the cluster? Wouldn't that make more sense?

I would not favor this.

As it seems, for symmetry that we what we want is to have a:

• push/unpush
• create/delete

But since the unpush seems too weird, it could be something else: e.g. remove (as it's more closer to what it will do, remove the deployed application from the cluster).

[jankleinert]

I like the idea of having as much symmetry in the commands as possible. What would you envision happening if someone runs delete but not unpush/remove? Or would you have to run unpush/remove before running delete? It seems like if we allow someone to run delete and it only removes the local config, then they would be in a weird state where they couldn't manipulate that deployed component from odo anymore.

…

On Mon, Apr 29, 2019 at 11:43 AM Jorge Morales Pou ***@***.***> wrote: How about changing odo delete to delete both (local config and from cluster) and odo destroy would just delete stuff from the cluster? Wouldn't that make more sense? I would not favor this. As it seems, for symmetry that we what we want is to have a: - push/unpush - create/delete But since the unpush seems too weird, it could be something else: e.g. *remove* (as it's more closer to what it will do, remove the deployed application from the cluster). — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1654 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAE7DUERQOUGVCECJQQCRWLPS4JP7ANCNFSM4HIV3I2A> .

[jorgemoralespou]

I think that when running delete, one should ask the user, Hey, you're deleting the odo config for this component but it's deployed. Do you want to remove it from the cluster?

But, most of the times they will only want to remove the application from the cluster, as the configuration will most likely want to go into the Git repo.

[girishramnani]

then we would need --force option too for non-interactive scenarios @jorgemoralespou, but issue here is that odo component delete already has a --force option. which means when now someone does --force then it will say yes to remove the component from cluster as well as yes to removing the component from the config. Is this an acceptable workflow?

[kadel]

then we would need --force option too for non-interactive scenarios @jorgemoralespou, but issue here is that odo component delete already has a --force option. which means when now someone does --force then it will say yes to remove the component from cluster as well as yes to removing the component from the config. Is this an acceptable workflow?

I think that in this case, we will need a second force flag, that will cause force deletion of both.
--force should just do the default action, and in this case, it will be deletion of the local configuration.

If I put everything together it would look like this:

• odo component remove - delete component form the cluster, leave the local configuration
  • It will ask for confirmation: "Do you want to remove the component from the cluster"?
  • --force flag that won't ask a question and delete it right away
• odo component delete - delete local configuration.
  • First, ask to confirm the deletion of local configuration: "Do you want to delete local odo config for a component?", then if the component is deployed "The component is deployed on the cluster, do you want to remove it from there?"
  • --force - will cause force deletion of both things (from the cluster and local config), no other questions
  • --force-remove - will force delete both

My only worry is that delete and remove are too similar, and it is not apparent will be what :-(
I'm sure that I'll confuse them all the time :-(

To achieve symmetry, and less confusion we could rename push to something else. Taking inspiration from docker-compose we could have up

• up/down
• create/delete

[girishramnani]

I would not prefer to have two different force flags. We can have an --all flag which asks for removal for local config and component and a --force to that does yes to both the question. Similarly the standard --force's functionality doesn't change.
This keeps the idea that --force makes a command non-interactive intact. And adds the required feature with least amount of changes to the interface.