odo delete fails for not pushed component

[jeffmaury]

[kind/bug]

What versions of software are you using?

• Operating System: Win10Pro
• Output of odo version:

odo v1.0.0-beta3 (c2b402e3)

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

How did you run odo exactly?

First, component was created but not pushed:
odo create java:8 sbcomp

then

$ odo delete
 X  failed to delete component sbcomp as it doesn't exist

Actual behavior

$ odo delete
 X  failed to delete component sbcomp as it doesn't exist

Expected behavior

$ odo delete
 X  Component sbcomp deleted

Any logs, error output, etc?

[girishramnani]

I think this is expected behavior because if we show Component sbcomp deleted then that would be misleading as in reality we are not doing anything on the cluster or locally and the only cleanup needed is the local config (.odo/config.yaml) which we only delete when provided with the --all flag (odo delete --all)

[jeffmaury]

Yes but the problem is that even if you pass the --all flag, the .odo/config.yaml will not get removed as odo claims the component does not exist

[girishramnani]

So I will consider the acceptance criteria for this issue to be that “—all” should remove the local odo config and not error out

[mik-dass]

@kadel @cdrage should we just change the error message or rewrite and make the run fail?

[cdrage]

@mik-dass IMO I think we should:

• Check the case where it exists in the config but is not pushed and output a different error message

[kadel]

odo delete --all should delete the local configuration even if the component doesn't exist, it should not error out in this case.

A little bit more complicated situation is when odo can't reach the cluster. In that case, it can't check whatever component exists in the cluster or not. If the connection fails and component exists in the cluster and we delete local config, then it will end up in inconsistent state and it won't be easy to delete the component from the cluster.

[dharmit]

IMO, classification like below would help avoid confusion.

Case 1: Component has been pushed to the OpenShift cluster

# When cluster is reachable, this should delete the pushed component and local config
$ odo delete --all

# When the cluster is not reachable, there's no way to confirm if component is pushed. 
# So, this should print appropriate error message and not remove local config
$ odo delete --all

Case 2: Component has not been pushed to the OpenShift cluster

# When the cluster is reachable, this should print an error message that component
# is not pushed and user can use `odo delete --all` to remove local config
$ odo delete

# When the cluster is reachable, this should print an info message that 
# component was not pushed to remote cluster and that local config has been removed
$ odo delete --all

# When the cluster is not reachable, there's no way to confirm if component is pushed. 
# So, this should print appropriate error message and not remove local config
$ odo delete --all

[mik-dass]

If the connection fails and component exists in the cluster and we delete local config, then it will end up in inconsistent state and it won't be easy to delete the component from the cluster.

@kadel So if the connection fails and we couldn't figure out if the component exists on the cluster or not, we just error out and don't delete the config, right?

[kadel]

If the connection fails and component exists in the cluster and we delete local config, then it will end up in inconsistent state and it won't be easy to delete the component from the cluster.

@kadel So if the connection fails and we couldn't figure out if the component exists on the cluster or not, we just error out and don't delete the config, right?

yes, that is correct

[mik-dass]

odo delete --all should delete the local configuration even if the component doesn't exist, it should not error out in this case.

@kadel What should be the behavior when the component name is passed like odo delete <non-existing-component-name> --all and the component doesn't exist?

[kadel]

if the current directory is component and it provided name matches the name from local config that proceed with the deletion. If the name is not matching error out.